Answers.Body: <p>Stored computed fields can be tricky because if you miss an update the stored value will be outdated. Implementing pre/post hooks <em>should</em> catch most updates that go through the UI and API, but of course would miss any updates done via direct SQL query (e.g. the deduping merger will do these).</p>
  <p><strong>Alternatives:</strong></p>
  <ol>
  <li><strong>An <a href="https://docs.civicrm.org/dev/en/latest/api/v4/fields/#calculated-fields" rel="nofollow noreferrer">APIv4 Calculated Field</a>:</strong> I recommend this if the calculation is not too difficult (e.g. just adding the values of a couple other fields together). The value will always be up-to-date and you won't have to worry about hooks.</li>
  <li><strong><a href="https://civicrm.org/extensions/summary-fields" rel="nofollow noreferrer">Summary Fields Extension</a>:</strong> Provides a framework for stored computed fields (the type you had in mind - a stored value in a custom field) but comes with pre-built management so you don't have to reinvent that wheel yourself.</li>
  <li><strong><a href="https://lab.civicrm.org/extensions/synopsis" rel="nofollow noreferrer">Synopsis Extension</a>:</strong> Similar to summary fields but more geared toward contact data. This might be what you want.</li>
  </ol>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-11-08T15:37:54.643Z
Answers.Text: Thanks Coleman, our computed field is unfortunately too complex to be covered by the alternatives mentioned above (the dependent fields live in different places, including relations, and business logic is not trivial). When you say 'pre/post hooks should catch most updates', do you mean we expect them to be fired in the 'Quick edit' case ?
Answers.UserDisplayName: Duf59
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-11-08T18:02:04.450Z
Answers.Text: I can't remember the specifics but I know we opted to use Synopsis for some calculated fields https://lab.civicrm.org/extensions/synopsis
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-11-08T15:04:34.367Z
Answers.LastActivityDate: 2023-11-08T21:42:05.537Z
Answers.LastEditDate: 2023-11-08T21:42:05.537Z
Answers.UserDisplayName: Coleman
Body: <p>We would like to implement a 'computed' custom field. Meaning a custom field A depends on the values of other custom fields B, C and D. We need this to work when editing the data via the CiviCRM admin or via the API.</p>
  <p>In order to achieve this we have started implementing some logic using the <a href="https://docs.civicrm.org/dev/en/latest/hooks/hook_civicrm_pre/" rel="nofollow noreferrer">hook_civicrm_pre</a>.</p>
  <p>The current hook works when modifying the contact information by clicking the &quot;Modify&quot; button at the top of the Contact detail page. However it does not work when modifying the data using 'quick edit' (for example clicking directly on the phone number field).</p>
  <p>Hence my question:</p>
  <ul>
  <li>how is the 'quick edit' different from the main 'modify' button, is the former using JS + the Civi rest API to modify the data ?</li>
  <li>what type of hook should we use so that it fires upon quick edit actions ?</li>
  </ul>
  <p>Thanks!</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2023-11-08T14:35:53.883Z
Comments.Text: It does work, you will need to catch correct Entity in pre hook
Comments.UserDisplayName: Pradeep Nayak
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2023-11-09T16:35:04.087Z
Comments.Text: I double checked by adding a log statement when entering the hook, and it is not triggered at all when doing 'quick edits', so not an issue with catching the correct entity or Op.
Comments.UserDisplayName: Duf59
Tags: <hooks>
Title: Triggering hooks upon quick edits
ThreadText: # Triggering hooks upon quick edits
  
  (Asked by: username_0 on 2023-11-08)
  
  We would like to implement a 'computed' custom field. Meaning a custom field A depends on the values of other custom fields B, C and D. We need this to work when editing the data via the CiviCRM admin or via the API.
  
  In order to achieve this we have started implementing some logic using the [hook\_civicrm\_pre](https://docs.civicrm.org/dev/en/latest/hooks/hook_civicrm_pre/).
  
  The current hook works when modifying the contact information by clicking the "Modify" button at the top of the Contact detail page. However it does not work when modifying the data using 'quick edit' (for example clicking directly on the phone number field).
  
  Hence my question:
  
  * how is the 'quick edit' different from the main 'modify' button, is the former using JS + the Civi rest API to modify the data ?
  * what type of hook should we use so that it fires upon quick edit actions ?
  
  Thanks!
  
  **Tags:** hooks
  
  > **Comments:**
  > **username_1**: It does work, you will need to catch correct Entity in pre hook  
  > **username_0**: I double checked by adding a log statement when entering the hook, and it is not triggered at all when doing 'quick edits', so not an issue with catching the correct entity or Op.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2023-11-08. Score: 3
  
  Stored computed fields can be tricky because if you miss an update the stored value will be outdated. Implementing pre/post hooks *should* catch most updates that go through the UI and API, but of course would miss any updates done via direct SQL query (e.g. the deduping merger will do these).
  
  **Alternatives:**
  
  1. **An [APIv4 Calculated Field](https://docs.civicrm.org/dev/en/latest/api/v4/fields/#calculated-fields):** I recommend this if the calculation is not too difficult (e.g. just adding the values of a couple other fields together). The value will always be up-to-date and you won't have to worry about hooks.
  2. **[Summary Fields Extension](https://civicrm.org/extensions/summary-fields):** Provides a framework for stored computed fields (the type you had in mind - a stored value in a custom field) but comes with pre-built management so you don't have to reinvent that wheel yourself.
  3. **[Synopsis Extension](https://lab.civicrm.org/extensions/synopsis):** Similar to summary fields but more geared toward contact data. This might be what you want.
  
  > **Comments:**
  > **username_0**: Thanks username_2, our computed field is unfortunately too complex to be covered by the alternatives mentioned above (the dependent fields live in different places, including relations, and business logic is not trivial). When you say 'pre/post hooks should catch most updates', do you mean we expect them to be fired in the 'Quick edit' case ?  
  > **username_3**: I can't remember the specifics but I know we opted to use Synopsis for some calculated fields https://lab.civicrm.org/extensions/synopsis  
  
  ---
  
  