We've hit problems with the GroupContact condition in CiviRules as it returns the
id column of
civicrm_group_contact_cache in its SELECT query to basically satisfy the question, "is the contact in a smart group?".
This is problematic for us as we've followed the general pattern of this core PR and removed the
id column from that table for performance reasons.
So in this PR I modify the query against the DB to return
civicrm_group_contact_cache rather than
I've also reworked the logic of this function so it only builds the smart group cache if the group being tested is a smart group.
CRM_Contact_BAO_GroupContactCache::check is wise enough to limit its operations to smart and parent groups only but it takes three functions (
groupRefreshClause) to get to that point.
I've tested this locally and on a fully populated dev instance. I tested against contacts that were in standard and smart groups. The rules fired as expected and no errors were logged.
I hope the PR and rationale behind it is suitable. Cheers!
PS. If this is an acceptable approach I can certainly add a commit to modify the CHANGELOG.