Details
-
Type: New Feature
-
Status: Done/Fixed
-
Priority: Important
-
Resolution: Fixed/Completed
-
Affects Version/s: 4.7
-
Fix Version/s: 4.7.19
-
Component/s: Core CiviCRM
-
Labels:
-
Versioning Impact:Minor (add functionality in backwards-compatible manner)
-
Documentation Required?:Developer Doc
-
Funding Source:Core Team Funds
-
Verified?:No
Description
Implement a prioritization and veto to the hook system (cfr. https://github.com/civicrm/org.civicrm.flexmailer/issues/1).
When we have implemented this, then we can move some of the core functions to being implemented as 'core hooks', ie core functions implemented as hooks, kinda having an extension shipped within core. Examples:
- the geo-coding of addresses can be implemented through the civicrm_post() hook
- the creation of related memberships can also be implemented through the civicrm_post() hook
- the event approval, capacity limit and waiting list features could potentially be implemented through hooks as well
- etc ...
Coupled with the prioritization and veto system, this would allow extension developers to complement or override the core business logic with their own. Examples:
- we could easily introduce geo-coding through another provider without touching core, or complement core geo-coding with assigning county and/or political districts based on geo-coordinates
- creation of related memberships could be re-written according to customer rules (ie. prioritize based on job title rather than contact_id as of now)
- implementation of the waiting list could be re-written according to customer rules (ie. prioritize based on past event attendance or membership level rather than order of registration)
Attachments
Issue Links
- links to