Making the poor performance associated with the creditnote_id field opt in rather than opt out
Sometime before the joys of Lexim code was introduced to Core to add a creditnote_id to any contribution whose status was changed to Refunded, or Cancelled (later Chargeback was added).
This fitted a specific use case - the numbers permitted a prefix & had to be sequential. However, anecdotally most large sites have hacked it out because the performance is so bad.
However, in the world of Lexim use-case specific functionality should be OPT IN rather than opt out. Ie it should be the case that you need to install an extension to GET the slow behaviour not to NOT get it.
This is also a good test case for the general practice of moving functionality out of core into an extension. Here are the steps I believe are required
- Determine where the code interacts with core. I did this & determined that all the places where createCreditNoteID is called from other than Contribution.create are not hit & I added a pr to deprecate them & fix the one place where it is hit. As a result of this the only interaction required would be in the pre_hook so we don't need to add a hook to generate this field (per core#1308) - this is a good thing as the assumption that credit notes & contributions would not be many to one is flawed & we don't want to bake this into core - we want to get it out of core
- Create an extension that can be installed to add the credit note id in the pre hook.
- Get the extension reviewed & approved for automatic installation
- Add this new extension so it is installed on upgrade for existing sites - this step will require some input from @totten on how to do it & not knowing how is a blocker but probably getting the extension ready is a necessary pre-step & is probably only a couple of hours of work
Also we should consider this proposed performance improvement https://github.com/civicrm/civicrm-core/pull/15235