Posted by nedjo on February 2, 2007 at 10:11pm
2 followers
Jump to:
| Project: | CiviNode And Civinode CCK |
| Version: | master |
| Component: | CCK Integration |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | postponed (maintainer needs more info) |
Issue Summary
We now have a great widget for linking a node to an existing CiviCRM contact. In some cases, though, we'll want to be able to create a new contact--as is done, e.g., when users are created.
For users, civicrm.module uses a hook_user() implementation to add a fieldset or fieldsets to the user register form, saving the results on submission.
What I have in mind is a parallel implementation for CCK nodes with a field linking to a contact. As well as linking to an existing contact, we can when submitting a node enter data to create a new contact, handled similarly to civicrm_register_data() in civicrm.module.
Comments? Pitfalls?
Comments
#1
Let me see if I understand you here....
CiviCRM's normal behavior in Drupal is to automatically create a new contact when a Drupal user is created. If the user creates this him/herself via user/register, you can create a "profile" (a group of fields you intend to use together) designated for use in User Registration; this allows you to make certain CiviCRM fields "required" for a new Drupal user.
This covers most use cases. If you're using a CCK data type as a "shadow" of Drupal user, then you'd want to get yourself inserted into the create contact process that's going to happen anyway.
Right now, the way you'd do this is with hook_civicrm_pre(), which CiviCRM calls before actually writing the contact into its data store.
So if you can tell me what behavior you want, I can probably tell you how to get the behavior. If it makes sense to make this more systematic -- say, you want to set a particular field in CiviCRM when the node (and its shadowed user) are created or edited -- then we may want to think about adding a new field type to the CiviCRM Data module.
One CCK feature I'm unclear about, which you could probably help me with: is it possible to create links between different fields in the same CCK data type? For example, to create a CCK data type that shadowed a Contact field, the CCK data type needs to track a CRM contact_id for any dependent field, and you want to make sure that if you change the contact for an instance of the data type, that all of its subordinate CCK fields change in lock-step.
Is there a good general way to do this in CCK? I'd guess that hook_node_api() could possibly do this, but it looks a little messy to me. There's also a possibility that you could have "race conditions" as one module tried to call the same $op in hook_node_api() before the other, and order mattered.
#2
Thanks for the response.
The issues are:
(1) the process of (a) create a CiviCRM contact (b) create a new node (c) in that node link back to the contact you created is cumbersome.
(2) not all contacts should be Drupal users.
Here's a use case. Users can register a new group, which should come with contact information and, say, a georeferenced location.
Ideally, instead of the three steps in (1), above, this is a one-step process--just like user registration is currently. Create the node, and (unknown to user) in doing so, have a fieldset (the equivalent of the current CiviCRM profile fieldset) in the node edit form, where the contact data can be added. User submits and a node is created, a contact is created, and the CCK contact field links to the new contact.
As well as simplfying the process, this shields the user from having to learn two different UIs, one for Drupal and one for CiviCRM.
I suspect that implementing it would be similar to what's currently done with the user hook in civicrm.module.
In terms of your question about selects, I don't know the relevant code well enough to offer a sound opinion. I see the issue. I guess it falls into the general category of "how do we limit the options in one field based on what's selected in another?" On the client side, this is not easy when we're dealing with autocomplete fields. There is an existing module for doing this with standard selects, http://drupal.org/project/activeselect. I guess the simplest might be a js behaviour that said, empty such and such a field when this field is updated. That way the user has to enter new (valid) data. On the server side I guess this is about validation.
#3
I guess the main implementation issue is the way CCK handles fields: the handlers are field (and not node) specific. What would help this issue (and the Views question you also posted today) would be some way of relating (and caching) data in the node object. I know that node_load does caching; the question is whether I can talk to that cache, or whether I need to maintain a CCK related node cache of my own.
Done this way, the different fields would write to the "CCK node cache".
As for linking back: the mechanism is hook_civicrm_links(), IiRC. The hook is called when a CiviCRM view page gets rendered. You'd check if the contact had a shadow CCK node, and if so, pass back the info needed for CiviCRM to render the link. I developed a version of this for the Bioneers that works with Contacts, and Lobo extended the concept in CiviCRM 1.5 and later to cover views for other data types.