Affects Version/s: 4.6.13, 4.7.2
Fix Version/s: Unscheduled
Epic Name:Fixes for group member caches
Versioning Impact:Patch (backwards-compatible bug fixes)
Funding Source:Needs Funding
There are a number of issues surrounding the ContactGroupCache - the list of members in a certain group that is generated to avoid having to query based on smart group criteria each time one is used.
I hope this epic can bring the issues together, so we can work together to solve them.
Our proposal, phase 1:
Group caches should only be rebuilt if the 'Smart group cache timeout' (in 'Search preferences') has passed.
Currently, it is rebuilt whenever users are added/removed (causing
It would also unify the experience between different areas of the site. Currently, the 'cached' list is used for CiviMail, for example, even if a contact has had some criteria change that would cause them to be present in the smart group.
Fixing the setting of the cache_date should also fix the issue in CRM-16642 - this would need to be tested, against using the order_by clause of the API when using scheduled jobs.
We can also scrap the 'refresh_date' column from the group cache table. It isn't currently set properly, and doesn't serve a purpose, since the refresh_date can be calculated dynamically based on the current time and the 'Smart group cache timeout'. (Especially considering the cache timeout could change.)
A PR for this is forthcoming.
Group caches should only be rebuilt using the 'Rebuild smart group cache' scheduled job - not when we try to access a cache and find it is out of date (comments on this welcome!)
^ We could then display a contact's smart group membership on their contact record. Otherwise the listing would check membership of every smart group on rebuild. If we can just check their membership of a group (cache) without triggering a rebuild then this information can be displayed.
Also, we could improve the UI on the manage groups page to display when a group was last 'rebuilt' and offer menu options to manually rebuild individual groups.
Potentially: make the cache timeout configurable per group, with a fallback to the default cache timeout.