Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
C
Core
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 983
    • Issues 983
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Incidents
  • Analytics
    • Analytics
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • Development
  • Core
  • Issues
  • #1638

Closed
Open
Opened Mar 09, 2020 by haystack@haystack🤔Developer

Introduce "civi.dao.preUpdate" and "civi.dao.preInsert" events

Overview

Following on from the action taken some time ago in Add civi.dao.preDelete event (and the proposal raised in #161 to an extent) it would be helpful to apply the same hook_civicrm_pre + hook_civicrm_post pattern to the Symfony events in CRM_Core_DAO::save(). I propose CiviCRM introduces civi.dao.preUpdate and civi.dao.preInsert events to complement the existing civi.dao.preDelete event.

Symfony events have advantages over "old-style" hooks of the form hook_civicrm_preSave. The old-style hook format is likely to lead some devs to write callbacks in the format extensionname_civicrm_preSave_table_name which are difficult to unhook or prevent from running endlessly. Symfony events can be unhooked and therefore make it relatively easy to avoid endless loops such as @colemanw raises concerns about in his comment. Also, they are largely undocumented and therefore avoid the effort of having to add to the Docs :-)

Example use-case

Let's look at what can be done with operations on "Option Value" data:

In both the CiviCRM Event Organiser and the CiviCRM ACF Integration plugins, I'd like to be able to inspect an Option Value before it is saved to the database so that I know what the full state of the Option Value was before the update is applied. Once the edit has happened, there's (obviously) no way of retrieving the required data.

(FWIW, this is to perform actions on synced entities in WordPress rather than modifying the Option Value before it is saved, but the same applies should Option Value data need to be modified.)

Current behaviour

As far as I can tell, there isn't a hook available for me to inspect an Option Value data prior to it being created or updated programatically. I partially solve this for changes made via the CiviCRM UI using the equivalent pre-post combination of hook_civicrm_preProcess and hook_civicrm_postProcess. However changes made via AJAX actions on the main "Event Type Options" listing screen can only be detected after the edit has been made.

Proposed behaviour

To mirror the pattern of hook_civicrm_pre + hook_civicrm_post and hook_civicrm_preProcess + hook_civicrm_postProcess and the existing pattern of civi.dao.preDelete + civi.dao.postDelete to complete the set with:

  • civi.dao.preInsert + civi.dao.postInsert
  • civi.dao.preUpdate + civi.dao.postUpdate

Comments

PR to follow.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
5.26.0
Milestone
5.26.0
Assign milestone
Time tracking
None
Due date
None
Reference: dev/core#1638