CiviCRM Community Forums (archive)

Hi,

I implemented a hook in Civi 1.4 or so to set the value of a contact custom field upon contact edit, based on the contact's postal_code. (It's for setting the electoral ward, from a look-up table). At the time I used hook_post, calling crm_update_contact. This worked but involves an extra db write.

I'm now re-implementing for 2.2 and considering better ways of doing it. I'm trying hook_postProcess; I've solved some parts of the puzzle like retrieving the postal_code from submittedValues and finding the correct element_name for the custom field (custom_X_Y) from groupTree. Not sure though what's the best way to actually update the custom field - do I need to poke a value into submittedValues & if so, how to achieve this - via set or setVar?

Or is hook_custom the thing to use here?

Thanks in advance for any tips.

Dave J

Documenting some discussion of this with Lobo on IRC:

[15:45] <davej_> Hello all. Looking for a recommendation of the best hook to use to set the value of a contact custom field upon contact edit, based on the contact's postal_code.
[15:49] <dlobo> u can use the civicrm_post hook
[15:49] <dlobo> on the contact object
[15:50] <dlobo> u could also use the postProcess hook for the contact edit form
[15:51] <davej_> I used civicrm_post when I implemented the same thing in Civi 1.4, calling crm_update_contact. But was thinking this involves an extra db write so wondered if hook_postProcess would be better.
[15:53] <dlobo> i think either would involve an extra db write
[15:52] <davej_> Or if civicrm_custom is relevant?
[15:53] <dlobo> in your specific case it is not
[15:53] <dlobo> since the edit form might not have any custom fields
[15:53] <dlobo> and that hook is fired only when we update custom fields
[15:54] <davej_> dlobo: ah,OK, I was imagining that hook_postProcess would allow poking a value into submittedValues before the contact write took place.
[15:56] <dlobo> no, we do our own writes
[15:56] <dlobo> before we call the hook
[15:56] <dlobo> a bit safer that way
...
[16:02] <davej_> dlobo: safer, yes, makes sense. So civicrm_contact_add in either civicrm_post or _postProcess. The latter would cover edits via the contact edit form, the former would cover all contact edits. Is that correct?
[16:04] <dlobo> yep
...
[18:29] <davej_> dlobo: hook_post worked OK but civicrm_contact_add generated another call to it - I'm able to avoid scary recursion but postProcess seemed a neater way of avoiding this. Working fine. Thanks for your help.
[18:30] <dlobo> davej_: r u doing another contact_add?
[18:30] <dlobo> in the post hook?
[18:31] <davej_> dlobo: yes, civicrm_contact_add to set the custom field values. Is that not what you'd meant?
[18:42] <dlobo> davej_: yeah, if calling it again, yeah u'll need to avoid recursion
[18:42] <dlobo> there are parameters to suppress hook invocation
[18:42] <dlobo> but we dont expose them to api
[18:46] <davej_> dlobo: right, so I could use a non-api fuction. Anyway working fine as it is. Thanks again, have a good weekend.

In the end I plumped for hook_post, as this site has various profile edit forms too. As a neater solution to avoiding recursion, I used CRM_Contact_BAO_Contact::create rather than API functions, as this provides the parameter $invokeHooks. This meant adding code to process the custom field values, along the lines of function _civicrm_custom_format_params in api/v2/utils.php . It would be nice if the $invokeHooks parameter were exposed to the API functions.

Thanks to Lobo. Hope this might help someone.

Dave J