New methodology for storing template contributions
Recurring contributions create new contributions based on a template.
Currently the template is the most recent contribution with a value in contribution_recur_id field equivalent to the recurring contribution.
The main issue with this is that if the contribution is deleted (e.g because it's far in the future & confusing) there is no way to create contributions against the recurring profile.
From a data model this idea of an 'implicit template' is far from ideal. However, a key challenge is that the template contribution holds references to custom data which is keyed by entity_id so using a table other than civicrm_contribution to store the template is highly fraught
At the sprint we concluded that the correct approach is to have the ability to store template contributions in a non-exposed way. To identify them we want to do BOTH
- create a new contribution status 'Template-only'
- add a new field is_template to the table
The reason for both is that we think is_template is the correct maintainable approach. However we think that many existing things won't search on it but WILL filter on contribution_status_id.
We will mitigate any impacts further by
- making is_template=0 a default criteria on apiv3, apiv4, BAO_Query
- not actually starting to create template transactions in core processes initially - processors that use it can drive the next stage of development
- BAO_Contribution::create() will ensure is_template & status are in sync.
- not permitting any UI editing of this field/ template contributions (until we build a specific UI)
The way this field WILL be initially usable is that the BAO_Contribution::getTemplateContribution function will attempt
- get contribution with is_template = 1 AND contribution_recur_id = x
- failing that fall back on existing latest contribution with contribution_recur_id = x