CiviCRM Community Forums (archive)

We deal with a site that uses ACLs in conjunction with Groups (using the multisite modules). They have experienced a few performance issues around the way in which smart groups and ACLs interact. I recently managed to patch one of them for them - I have pasted the patch below - although it is not a real fix - just a hack to work around the need to improve the smart group code (per the MIH which didn't fly). Note that our site uses the multisite module which applies permissions according to group hierarchy - the issues are general to ACLs, however.

Realistically the MIH is needed & I hope that sooner or later we'll get the $$ behind it or someone will jump in & fix it (I did spot some patches flying on IRC recently :-) but for now I'm just seeking to document the issues I've seen.

It is currently NOT possible to show smart groups on contact dashboards because the process of resolving a person's smart groups is too intensive (this was the focus of the MIH). However, when a user with less than 'view all contacts' attempts to view a contact's dashboard, or, worse, their groups tab the code is attempting to resolve all the person's smart groups in order to determine if the logged in user is entitled to view them.

This might make sense but the queries it triggers don't (one hit 53 hours before someone killed it) so I have applied the patch below which solves the symptom if not the problem. It possibly circumvents some clever aspect of the permissioning system but....

Index: civicrm/CRM/Contact/BAO/Contact.php
===================================================================
--- civicrm/CRM/Contact/BAO/Contact.php (revision 1317)
+++ civicrm/CRM/Contact/BAO/Contact.php (revision 1314)
@@ -2180,7 +2180,7 @@
             
         case 'group':
             require_once 'CRM/Contact/BAO/GroupContact.php';
-            return CRM_Contact_BAO_GroupContact::getContactGroup( $contactId, null, null, true, true );
+            return CRM_Contact_BAO_GroupContact::getContactGroup( $contactId, null, null, true );
             
         case 'log' :
             require_once 'CRM/Core/BAO/Log.php';
Index: civicrm/CRM/Contact/Page/View/GroupContact.php
===================================================================
--- civicrm/CRM/Contact/Page/View/GroupContact.php (revision 1317)
+++ civicrm/CRM/Contact/Page/View/GroupContact.php (revision 1314)
@@ -46,11 +46,11 @@
      */
     function browse( ) {
   
-        $count   = CRM_Contact_BAO_GroupContact::getContactGroup($this->_contactId, null, null, true,true);
+        $count   = CRM_Contact_BAO_GroupContact::getContactGroup($this->_contactId, null, null, true);
         
-        $in      =& CRM_Contact_BAO_GroupContact::getContactGroup($this->_contactId, 'Added',null,null,true );
-        $pending =& CRM_Contact_BAO_GroupContact::getContactGroup($this->_contactId, 'Pending' ,null,null,true );
-        $out     =& CRM_Contact_BAO_GroupContact::getContactGroup($this->_contactId, 'Removed' ,null,null,true );
+        $in      =& CRM_Contact_BAO_GroupContact::getContactGroup($this->_contactId, 'Added' );
+        $pending =& CRM_Contact_BAO_GroupContact::getContactGroup($this->_contactId, 'Pending' );
+        $out     =& CRM_Contact_BAO_GroupContact::getContactGroup($this->_contactId, 'Removed' );
 
         $this->assign       ( 'groupCount'  , $count );
         $this->assign_by_ref( 'groupIn'     , $in );

The second issue relates to hierarchical groups. Smart group caching records all the contacts that meet the groups criteria in the group_contact_cache table. If a group is in a hierarchy then that data is populated for the current group, and it's parents up the chain.

A smart group of 'All Individuals' created within the group 'Timbuctoo' may only contain 3000 people and that would be cached in the table. The parent group, Mali, may, however, contain 30,000 and the parent of that 300,000 people. As a result 333,000 records are added to the group_contact_cache table. In this case the option (possibly site-wide) of allowing smart groups to be restricted by their parent groups, rather than to extend them would probably solve the problem.

Note that you can't include membership of the parent group in the smart group criteria or you create a circular group.