dev/core#1093: Bckport Fix to v.5.19 to Add Custom Fields to Logging Tables

[MiyaNoctem]

Overview

This fix was recently merged to master on this PR #15599.

As a regression issue injected when changing the method used to create custom fields, we need to back-port it into v5.19 rc branch.

We recently ran into problems with direct debit extension due to this change. Basically, if someone has logging enabled, and tries to install the extension, a fatal error will be thrown, complaining about a non-existing field.

Before

The problem happens when a custom field is added via XML file on installation of an extension, logging is turned on, and part of the installation process inserts information on that new field. This happens, because the procedure used to install an extension is something like:

1. Process .xml files (creating custom groups and fields):
   1. Creates custom group table, custom group log table, and triggers to update log table.
   2. Creates custom group fields - WITHOUT creating fields on custom group log table.
2. Runs install steps on Upgrader.php for the extension
3. If logging is turned on, syncs every table that was modified with their corresponding log table.

So, if we include any updates on the new custom group tables on Upgrader.php, the trigger will be fired to update the table's corresponding logging table, and fail, as the new fields will not exist on the log table.

After

Fixed by building log table after all fields are added to main table, and resetting the cache mapping tables with its columns before calling fixSchemaDifferences() at the end of extension installation.

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[MiyaNoctem]

@eileenmcnaughton, here's the PR to backport the fix to v5.19.