Affects Version/s: 1.4
Fix Version/s: None
Component/s: Technical infrastructure
I've started back at integrating Drupal organic groups with CRM, this time with 1.4 as the target version.
This is doable, but since I may be the only user of the code path so far, I strongly recommend changing the calling conventions of the new hook so that it is (1) more consistent with other uses of hook_civicrm_pre and hook_civicrm_post, and so that civicrm_pre can screen which ids are actually added or deleted from a group.
To see why the current situation is unsatisfatory, look at how the hook is called for an Individual or a Group.
First, look at the prototypes for the hooks (from CRM/Utils/Hooks.pre):
static function pre( $op, $objectName, $id, $params = null );
static function post( $op, $objectName, $objectId, &$objectRef );
I don't have a lot of examples of the pre hook. But for post:
Add a contact:
CRM_Utils_Hook::post( 'create', $params['contact_type'], $contact->id, $contact );
Delete a contact:
CRM_Utils_Hook::post( 'delete', $contactType, $contact->id, $contact );
Group is similar. But here's what you have now for GroupContacts:
Add a list of contacts to a group:
CRM_Utils_Hook::post( 'create', 'GroupContact', $contactIds, $groupId );
Remove a group of contacts from a Group:
CRM_Utils_Hook::post( 'edit', 'GroupContact', $contactIds, $groupId );
First, the order is just weird. Remember that the prototype of the Drupal hook is:
function hook_civicrm_post($op, $objectName, $objectId, &$objectRef);
So $objectId is going to be an array in this case, and $objectRef is an ID. Confusing. And it will
make for less readable code in the Drupal module, since it is going to be doing very different things with both $objectId and $objectRef depending upon context.
Second, 'edit' is only called for deletion. This is not what a module writer would expect either.
Certainly, documentation will help here, but I think it would be better if the call in this case were more in line with other uses of the hook.