Details
-
Type: Bug
-
Status: Open
-
Priority: Minor
-
Resolution: Unresolved
-
Affects Version/s: 4.4.6
-
Fix Version/s: Unscheduled
-
Component/s: None
-
Labels:None
-
Versioning Impact:Patch (backwards-compatible bug fixes)
-
Documentation Required?:Developer Doc
-
Funding Source:Needs Funding
Description
1. Create an extension with a hook_civicrm_post and a hook_civicrm_postprocess that output (i.e. drupal watchdog) describing their state.
2. Create an individual with a custom field
3. Edit the individual's name using inline editing (not by clicking the edit button). Change it and save. Observe in the logs that the postprocess hook and the custom hook fire.
4. Edit the individual's custom data using inline editing (not by clicking the edit button). Change it and save. Observe in the logs that this time only the custom hook fires.
In our custom data there were both text and select types of custom data.
More examples
#1 If I use the JS inline editor for a contact and update a group of custom fields: _pre and _post are not called, but _custom is called.
#2 If I put custom fields on a profile, and update it: _pre IS called (for the 'Profile') entity, and contains the value of the custom field. Then _custom is also called. Then _post.
#3 API calls presumably (I haven't tested this) always trigger _pre and _post, and therefore also _custom, because they always target a Civi entity.
This effectively means that you can't rely on _post to pick up all database updates; and you can't really use _post and _custom because they might both be called.
Proposed resolution
Ensure that _pre and _post are called consistently in all circumstances. Custom fields are always attached to an entity, so we should be able to use the existing functions. The only trouble is making sure _pre and _post aren't called twice, like in example #2 above.
Deprecate the _custom hook with a notice that it will be removed in a future version (which version?).