Details
-
Type:
Bug
-
Status: Done/Fixed
-
Priority:
Major
-
Resolution: Fixed/Completed
-
Affects Version/s: 3.1.5, 3.1.6, 3.2, 3.2.1, 3.2.2, 3.2.3, 3.2.4, 3.2.5, 3.3.0, 3.3.1
-
Fix Version/s: 3.3.2
-
Component/s: Core CiviCRM
-
Labels:None
Description
When the php date function is used under Drupal, timezone adjustments are applied after getting the system time. Using user-configurable timezones, the cache times are going to be stale or in the future depending on who is running the query at that moment. This affects how the group cache table is updated.
In CRM/Contact/BAO/GroupContactCache.php::remove() the cache date is set with $now = date( 'YmdHis' ) but later compared with MySQL NOW(). This presents a problem when Drupal is using user-configurable timezones since $now is going to be different depending on what timezone the person issuing the query is in. The fix is to use the same source of time to set and compare timestamps. Either the system time from MySQL NOW() or if you want to skip making that extra database call, use date() but set the timezone first.
date_default_timezone_set('UTC'); // pick a zone, any zone; just be consistent
$now = date('YmdHis');
Scanning through the rest of the CiviCRM code, GroupContactCache.php appears to be the only file that compares $now to NOW() but obviously it affects other areas of CiviCRM. This most recently came up when trying to troubleshoot why CiviReport was return 0 contacts for a smart group. See http://issues.civicrm.org/jira/browse/CRM-7207
Attachments
Activity
The patch addresses the problem we were having with user configurable timezones. We also needed to set the cache_date to NULL for our smart group so the code could update with the proper time/date stamp.
thanx for the patch. the update also resets all db caches so all smart groups are recalculated when needed
Reopening to set Fixed For version (3.3.2)
Attached is a patch against 3.3 branch (r31362) that fixes #
CRM-7246, #CRM-6855.