Author Topic: Idea: webform_civicrm module to allow arbitrary API calls (Read 2986 times)

Coleman Watts · November 14, 2011, 10:55:21 pm

Hi everyone. I've been having fun writing the Webform CiviCRM Integration module, and just had an interesting idea:
In essence this module provides a GUI for executing CiviCRM API calls, and so far it does this in a very structured way. Choose your options, and then on form submissions it will automatically call 'contact_create' or 'relationship_create' or 'participant_create' etc. using predefined params.

So here's my idea: what about adding a feature that allows the user to call any api function and set any params (params would be either the result of a webform field, or a static value).

It would be nice to provide some structure though. Is it currently possible to know what fields are available to each API? What about knowing which ones are required?

Here's a little mockup I did with firebug. It shows the basic concept. The reason I'm excited about this idea is that I get lots of feature requests for the module, but adding new features is time-consuming and really bloats the code. A recent example: can this module create events? Well, creating events via the api is easy. The hard part is making a GUI for it on the webform_civicrm config page. This way adding new features to the module would basically be "self service."

Eileen · November 14, 2011, 11:08:47 pm

"Is it currently possible to know what fields are available to each API? What about knowing which ones are required?"

The getfields action is the key to this.

getfields takes an optional param 'action'

Note api is a good example as it demonstrates 'required' & 'default' params as well as different params - take a look at the phpdoc for it

http://api.civicrm.org/v3/CiviCRM_APIv3/API_Tag/_api---v3---Tag.php.html#functioncivicrm_api3_tag_create

Erik Hommel · November 14, 2011, 11:18:41 pm

I am torn (is that a song I have seen a nice little video impression on?)

I really love the idea of having a GUI like that, and I can see the advantages from a development point of view..my developer side goes YESSSSS......but the other side of me finds it hard to get a use case together? Am I missing the point?

xavier · November 14, 2011, 11:25:11 pm

Hi,

Have a look at the api explorer, what is does when you create is close than that, but
1) it displays the list of fields first (bold if required)
2) if adds the field when you click on it

I did it that way for two reasons: it creates very long forms (eg for contacts), and some of the fields are very technical/never used directly/never used and not having the field is potentially different than having an empty field.

it currently doesn't take into account the type (int, string...), but patch welcome

Part of the issue to make it less technical and more end user friendy is that
1) the "required" attribute is 'creatively' set, and needs to be taken with a pinch of salt
2) some required are "this one OR that one" some are "AND", some are complicated
3) the normal name versus unique name issue means that you can't know which one you put.

What I've been thinking of doing in the same vein of your idea is to use a jqgrid, so you can update/create in batch (using the ajax api). That's something that would be awesome!

X+

P.S. svn update on 3.4 to see the create in action, I'm fixing on the other versions soon

Coleman Watts · November 15, 2011, 09:25:25 am

Thanks for the help and tips!
Just want to clarify something: unlike the API explorer, this would not be an interface for making immediate calls to the API. Like everything else in this module, the calls would be executed upon a webform submission.
So Erik, the use case is this:
Currently this module can do lots of things upon webform submissions, but there's still lots of things it can't do, such as creating memberships, or events, or groups, etc. This would bridge the gap and allow users to DIY just about any feature with a (hopefully) not-too-confusing GUI.

Erik Hommel · November 15, 2011, 09:54:10 am

Coleman, I have high hopes of the GUI considering our musical talents as a group

. I accept the use case, but I certainly do not have customers that are that computer literate, let alone Civi literate...............

Coleman Watts · November 25, 2011, 08:45:07 am

A few more questions to make this happen:
1) How do you determine what apis are available? Is there a function that scans the api/v3 directory that I can take advantage of?
2) For each API, how do you determine what methods are available? Most apis provide "get" "create" and "delete" but some do not, and some have others.

xavier · November 25, 2011, 11:44:18 pm

1) api.entity.get is your friend
2) You should assume that get create and delete exist. When it doesn't make sense (eg. entity.create) we try to provide an always failing result
3) In my mythical "soon when I have some time" I'd write a getAction that would return all the actions available for one entity

X+

xavier · November 26, 2011, 01:10:34 am

Turns out that I implemented it
http://issues.civicrm.org/jira/browse/CRM-9232

use the getActions that should return the list of actions for that entity (duh)

X+

CiviCRM Community Forums (archive)

News:

Author Topic: Idea: webform_civicrm module to allow arbitrary API calls (Read 2986 times)

Coleman Watts

Idea: webform_civicrm module to allow arbitrary API calls

Eileen

Re: Idea: webform_civicrm module to allow arbitrary API calls

Erik Hommel

Re: Idea: webform_civicrm module to allow arbitrary API calls

xavier

Re: Idea: webform_civicrm module to allow arbitrary API calls

Coleman Watts

Re: Idea: webform_civicrm module to allow arbitrary API calls

Erik Hommel

Re: Idea: webform_civicrm module to allow arbitrary API calls

Coleman Watts

Re: Idea: webform_civicrm module to allow arbitrary API calls

xavier

Re: Idea: webform_civicrm module to allow arbitrary API calls

xavier

Re: Idea: webform_civicrm module to allow arbitrary API calls