Fix trigger generation for modified_date on custom data
authoreileen <emcnaughton@wikimedia.org>
Tue, 17 Apr 2018 00:03:00 +0000 (12:03 +1200)
committereileen <emcnaughton@wikimedia.org>
Tue, 17 Apr 2018 05:44:13 +0000 (17:44 +1200)
commit6bbc383dc4c9070079986235fa145cafc3c72eeb
tree8367196cd5108ca91259328e98537262d46f9d0a
parent37c97defaa47f9fbdbbd882d288955dd11259f1f
Fix trigger generation for modified_date on custom data

In 4.7.25 https://github.com/civicrm/civicrm-core/pull/10754/commits introduced
some modifications to the generation of triggers to update the modified date field.

It basically derived the entity being extended by a table and then if that entity had a
modified_date field then a trigger would be created to update that field.

However, a bug in the CRM_Core_BAO_CustomGroup::getAllCustomGroupsByBaseEntity function
meant that incorrect additional tables are also being updated for custom fields.

For entities extending contact the contact table AND the mailing table are updated. e.g
```
CREATE TRIGGER {mycustomtable}...
UPDATE civicrm_contact SET modified_date = CURRENT_TIMESTAMP WHERE id = NEW.entity_id;

UPDATE civicrm_mailing SET modified_date = CURRENT_TIMESTAMP WHERE id = NEW.entity_id;
```

For entities that extend tables that should not attract a trigger ONLY
the mailing table is updated.

The bug in CRM_Core_BAO_CustomGroup::getAllCustomGroupsByBaseEntity is that it adds the
WHERE clause 'AND extends IN ($entityType)' ONLY if $entityType is in a whitelist.

Invalid entities result in no filtering.

As a fix using a whitelist is no longer valid - we support any entity that might
be configured now so simply filtering on the entity makes sense.

Other paths to this function seem unlikely to pass in invalid entities & hence trigger this bug.
CRM/Core/BAO/CustomGroup.php
tests/phpunit/CRM/Logging/SchemaTest.php