Answers.Body: <p>Ugh. This kind of bug is really hard to diagnose. Good call on noticing that memcache caches this behavior.</p>
  
  <p>Are you on some kind of host with really aggressive caching by default? WPEngine, for example, has caused big problems.</p>
  
  <p>If not, you should report this on issues.civicrm.org. My hunch is that caching/retrieval of the query for visiting the contact summary happens before the ACLs for custom fields are checked.  </p>
  
  <p>You may be able to more reliably test this by creating a user <em>not</em> in Role 1 and logging in as them.  I'd be curious if one or both of the following happen:
   - visiting the contact as the non-privileged user causes the privileged user to not see the fields the next time
   - visiting the contact as the privileged user causes the non-privileged user to see the fields the next time (if so, a bad security problem)</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-06-10T12:53:34.147Z
Answers.Text: We're hosting it ourselves and aren't doing anything special caching-wise. Good idea re troubleshooting.
Answers.UserDisplayName: sdragnev
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-06-10T11:26:08.077Z
Answers.LastActivityDate: 2015-06-10T11:26:08.077Z
Answers.UserDisplayName: Andie Hunt
Body: <p>We recently started using ACLs to fine-tune access to custom fields. Roughly speaking, our setup is:</p>
  
  <ul>
  <li>all <em>authenticated users</em> can access custom field group 1</li>
  <li><em>role 1</em> can access field groups 2, 3, 4</li>
  <li><em>role 2</em> can access field group 5</li>
  </ul>
  
  <p>The problem is that once in a while, a user with <em>role 1</em> can't see fields in groups 2, 3 and 4 when looking at a contact's summary page.
  Refreshing the page fixes the issue.</p>
  
  <p>Unfortunately, if we are using memcache, refreshing no longer helps (which makes sense).</p>
  
  <p>What would cause Civi to not correctly check ACL permissions once but then work on the second attempt?
  Of course this appears to happen completely randomly and is impossible to recreate consistently.</p>
  
  <p>Running CiviCRM 4.6.2.</p>
  
  <p><strong>UPDATE</strong>: Issues appear to start during Drupal's cron run.</p>
  
  <p>/CRM/ACL/BAO/ACL.php:group() returns erratic and inconsistent arrays of custom field group IDs every time it gets called.
  Seems like drupal's cron wreaks some sort of havoc on the acl cache and civi has a hard time rebuilding it.</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-01-26T10:21:12.973Z
Comments.Text: Have seen similarly erratic and inconsistent results for profile ids on a 4.6.24 . Did you file a JIRA issue?
Comments.UserDisplayName: davejenx
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-01-26T16:24:35.940Z
Comments.Text: @davejenx I don't think an issue was logged at the time. We stopped using ACLs because of the performance hit. We had enough problems dealing with group cache in the first place. Things may have improved in 4.7 since.
Comments.UserDisplayName: sdragnev
Tags: <acl><cache>
Title: Inconsistent ACL behaviour
ThreadText: # Inconsistent ACL behaviour
  
  (Asked by: username_0 on 2015-06-09)
  
  We recently started using ACLs to fine-tune access to custom fields. Roughly speaking, our setup is:
  
  * all *authenticated users* can access custom field group 1
  * *role 1* can access field groups 2, 3, 4
  * *role 2* can access field group 5
  
  The problem is that once in a while, a user with *role 1* can't see fields in groups 2, 3 and 4 when looking at a contact's summary page.
  Refreshing the page fixes the issue.
  
  Unfortunately, if we are using memcache, refreshing no longer helps (which makes sense).
  
  What would cause Civi to not correctly check ACL permissions once but then work on the second attempt?
  Of course this appears to happen completely randomly and is impossible to recreate consistently.
  
  Running CiviCRM 4.6.2.
  
  **UPDATE**: Issues appear to start during Drupal's cron run.
  
  /CRM/ACL/BAO/ACL.php:group() returns erratic and inconsistent arrays of custom field group IDs every time it gets called.
  Seems like drupal's cron wreaks some sort of havoc on the acl cache and civi has a hard time rebuilding it.
  
  **Tags:** acl, cache
  
  > **Comments:**
  > **username_1**: Have seen similarly erratic and inconsistent results for profile ids on a 4.6.24 . Did you file a JIRA issue?  
  > **username_0**: @username_1 I don't think an issue was logged at the time. We stopped using ACLs because of the performance hit. We had enough problems dealing with group cache in the first place. Things may have improved in 4.7 since.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2015-06-10. Score: 3
  
  Ugh. This kind of bug is really hard to diagnose. Good call on noticing that memcache caches this behavior.
  
  Are you on some kind of host with really aggressive caching by default? WPEngine, for example, has caused big problems.
  
  If not, you should report this on issues.civicrm.org. My hunch is that caching/retrieval of the query for visiting the contact summary happens before the ACLs for custom fields are checked.
  
  You may be able to more reliably test this by creating a user *not* in Role 1 and logging in as them. I'd be curious if one or both of the following happen:
  - visiting the contact as the non-privileged user causes the privileged user to not see the fields the next time
  - visiting the contact as the privileged user causes the non-privileged user to see the fields the next time (if so, a bad security problem)
  
  > **Comments:**
  > **username_0**: We're hosting it ourselves and aren't doing anything special caching-wise. Good idea re troubleshooting.  
  
  ---
  
  