Migrate hook_civicrm_caseTypes to hook_civicrm_managed
Overview
Since v4.x, hook_civicrm_caseTypes
has provided a way to register a case-type using a stored file from an extension. hook_civicrm_managed
was recently expanded (#3429 (closed) for 5.50) in a way that appears to provide a superset of the functionality. During review of @herbdool's https://github.com/civicrm/civicrm-core/pull/23313, @colemanw suggested deprecating hook_caseTypes
in favor of hook_managed
.
This issue is to identify the steps/phases of a migration.
Pro/Con
- Reasons to transition
hook_civicrm_caseTypes
=>hook_civicrm_managed
- They support the same use-case. Having more than one way to do the same thing can be confusing.
-
hook_managed
is more generic. You get more utility/leverage from understanding it. -
hook_managed
has more options vis-a-vis lifecycle, cleanup, etc.
- Reasons not to transition
hook_civicrm_caseTypes
=>hook_civicrm_managed
- If it ain't broke, don't fix it.
-
hook_caseTypes
has multiple mappings which appear to work together (ieCRM_Case_ManagedEntities
:CaseTypes
,ActivityTypes
,RelationshipTypes
). - This specific application of
hook_managed
is new. Needs more usage to see if it's fit-to-purpose.
Transition Path
IMHO, the transition would look something like this:
- Near term / Phase 1
- Do some testing around extension lifecycle/upgrades - eg if you upgrade an extension (getting a new CaseType
definition
that adds, edits, removes some ActivityType), then... do the interdependent things update properly? What happens if you've edited theActivityType
locally or added anotherActivityType
? Do policies likecleanup=>unmodified
orcleanup=>unused
actually work? (I expect these to be somewhat sensible, since each part seems to have satisfactory precedent; but I encourage playing with it during QA, since this is a bit unusual and it's important to the story of "managed CaseType".) Perhaps publish an example extension that shows that the technique is fit-for-purpose.
- Do some testing around extension lifecycle/upgrades - eg if you upgrade an extension (getting a new CaseType
- Mid-term / Phase 2
- Add some docs which tell the story of exporting via
civicrm/api4
-- eg an alternative to https://docs.civicrm.org/dev/en/latest/extensions/civix/#generate-case-type - Try doing a conversion from
xml/case/*.xml
to*.mgd.php
. Make sure that IDs/FKs (case_type_id
,activity_type_id
, etc) are stable. - Remove https://docs.civicrm.org/dev/en/latest/extensions/civix/#generate-case-type and maybe
civix generate:case-type
(Leave a pointer to the new docs.) - Update
CRM_Case_ManagedEntities
and/ormixins/case-xml
to emit a warning. Encourage folks to convert tomgd
. - (Stretch goal) Add a step to
civix upgrade
to auto-convert*.xml
to*.mgd.php
(or at least show a warning about the XML files). (See also: https://github.com/totten/civix/tree/master/upgrades)
- Add some docs which tell the story of exporting via
- Long-term / Phase 3
- Remove
hook_caseTypes
akamixins/case-xml
from core - Remove
hook_caseTypes
akamixins/case-xml
from civix
- Remove