Answers.Body: <p>The 'fix' on my particular set up was to give 'View' permissions to the Group that was allocated to see that layout.  It might be because we are quite locked down, but the code was failing to list the group or groups that were allocated to this layout (see my comments above)</p>
  <p>I tested this by adding another plain group (i..e non ACL etc) called testLayout and adding this group to the Contact Layout.  So now any user in either one of these groups should be able to see the said Contact Layout. When I added a user to the testLayout group, they were unable to see the Contact Layout, but when I gave View permissions to the testLayout group for that user, it all worked fine.</p>
  <p>So I am not sure if this is working as intended, but that has been the solution that I'll be looking at implementing after a bit more testing.  Fortunatley, the permissions are layered for me so that people (staff group) have permissions to View the people already in the Team leaders group, as these people are also in the Staff group as well.</p>
  <p>It does seem odd though - I would have thought the code would just need to get a list of all groups regardless of who was logged in for this particular check (the code states it is to check for missing groups)</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-07-14T11:43:43.990Z
Answers.LastActivityDate: 2023-07-14T11:43:43.990Z
Answers.UserDisplayName: ChumKui
Answers.Body: <p>So far as I know, it's not as complex as you're suggesting.  It's not using ACL's or CMS permissions, just Civi Groups.  The readme says:</p>
  <blockquote>
  <ul>
  <li>The &quot;Show&quot; option can specify a contact type, e.g. if a layout is specifically designed for Organization contacts rather than Individuals.</li>
  <li>The &quot;To&quot; option can restrict a layout to be visible to only certain logged-in users (e.g. show one layout to your volunteers and another to your staff).</li>
  <li>When a user views a contact, the first layout in the list which meets the &quot;Show&quot; and &quot;To&quot; criteria will be shown.</li>
  <li>If no layout matches the criteria, the default system layout will be used.</li>
  </ul>
  </blockquote>
  <p>I'm not sure what you mean by 'not seeing the layout labels'. The two following screenshots show the layout labels (or is that showing what you expect to see and aren't?)  What happens if you switch to a different theme to rule out any Shoreditch oddities?  Are there any javascript errors in the browser console?</p>
  <p>I've just tried this on dmaster and the system default fallback works as expected when not in a group with a non-default layout.</p>
  <p>==edit==
  (It's easier to read here than in a comment)</p>
  <p>The layout is determined by <a href="https://github.com/civicrm/org.civicrm.contactlayout/blob/master/CRM/Contactlayout/BAO/ContactLayout.php#L16" rel="nofollow noreferrer">CRM_Contactlayout_BAO_ContactLayout::getLayout()</a> which calls <a href="https://github.com/civicrm/org.civicrm.contactlayout/blob/master/CRM/Contactlayout/BAO/ContactLayout.php#L16" rel="nofollow noreferrer">checkGroupFilter()</a> to filter the layouts based on the contact's groups.</p>
  <p>If you have <code>cv</code> installed you could check what results you get for your colleague:</p>
  <p><code>cv ev -U admin 'print_r(CRM_Contactlayout_BAO_ContactLayout::getLayout(CID, UID));'</code></p>
  <p>Replace 'CID' with the contact id of any individual.<br>
  Replace 'UID' with the contact id of your colleague.<br>
  If you don't have a CMS user called 'admin' replace that too.</p>
  <p>If you get nothing returned, they should see the default layout.</p>
  <p>Are there any errors in your errorlog?</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-11-02T21:02:58.560Z
Answers.Text: I have been all through the readme and taken a look on Github.  I've also tried turning Shoreditch on and off.  The question is what dictates that a user actually gets to see the Contact Layout label.  I was showing what I would expect to see - logically, you will either see the layout you are entitled to see and the associated label for the layout, or, you will fallback to see the Default Layout and again, the associated label for that layout?  I am not seeing that for a certain class of user and so that is my question - it must be my set up in some way.
Answers.UserDisplayName: ChumKui
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-11-03T09:58:06.633Z
Answers.Text: See edits to answer
Answers.UserDisplayName: Aidan
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-11-20T12:26:28.360Z
Answers.Text: Thanks Aiden, I'll go back to look at this and try to debug it using CV. Clearly not my lucky month as importing contacts seems to have broken now...!
Answers.UserDisplayName: ChumKui
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-07-13T14:41:24.233Z
Answers.Text: It has been a while but revisiting this as I'd love to get it working.  I recreated this using an out of the box CiviCRM install with generated data so I had users and groups.  Created a single layout called Elevated and it all worked flawlessly, falling back to the System Default.  I used the call via cv to CRM_Contactlayout_BAO_ContactLayout to see how it all worked (thanks for the tip).  However, it still fails to work like this on my system.  When I log in as a user who is not part of the group I've set for that, cv correctly shows what amounts to a null return, but it does not fall back?
Answers.UserDisplayName: ChumKui
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-07-13T14:49:47.830Z
Answers.Text: Just to add to my comment above, when I run the cv call on a user that is in the single group that can see this test layout, it correctly shows the layout name, the arrays of data displayed and the array of the groups that user is part of to see this layout data. I did manage to get it to work by using an intermediary group.  I created a copy of system default, and set the group to be our main staff group.  So this is a pseudo fallback as all staff are in this group and it correctly displays the limited data, again, the cv call displays the correct data arrays
Answers.UserDisplayName: ChumKui
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-07-13T16:59:35.940Z
Answers.Text: Hi Aiden - sorry for the continual comments.  This drove me mad so I've gone through this with the debugger (and now found a buried error message in the logs I missed...) The issue appears to be that the logged in user cannot 'see' the group - it fails on line 66 of ContactLayout.php when the call in line 61 to get the Group ID returns an empty array.  It logs with 'Cannot filter on nonexistent group'.  So this is my setup in some way, but it must be a bug? Now to understand what is locked down to stop non admin users operating properly.
Answers.UserDisplayName: ChumKui
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-11-02T20:51:11.743Z
Answers.LastActivityDate: 2022-11-03T09:57:36.070Z
Answers.LastEditDate: 2022-11-03T09:57:36.070Z
Answers.UserDisplayName: Aidan
Body: <p>I am testing Contact Layout and I have what I think is a permissions issue to see the layouts.  We use Drupal 7.92 and CiviCRM 5.54, Contact Layout is v2.1.1.</p>
  <p>I have installed Contact Layout and have created a single additional layout called Elevated. The Elevated layout is a clone of the system fallback, with just the addition of the Demographics block:</p>
  <p><a href="https://i.sstatic.net/ue4m7.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/ue4m7.png" alt="enter image description here" /></a></p>
  <p>The Display Preferences exclude the Demographic block for all users and this is rightly (I believe) reflected by the System Default layout.</p>
  <p>If you are a member of one one of four ACL groups, I want you be able to view (if you have permission) Individuals, of any contact subtype, with the addition of the Demographics block:</p>
  <p><a href="https://i.sstatic.net/qqSTw.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/qqSTw.png" alt="enter image description here" /></a></p>
  <p>This works perfectly when I personally log in as a user that is a member of one of those groups.</p>
  <p><a href="https://i.sstatic.net/2CGod.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/2CGod.png" alt="enter image description here" /></a></p>
  <p>The issue is it does not fall back if I log in as a user that is not in one of those groups - the Demographic block is still displayed.  Also, I do not see the Layout labels,</p>
  <p><a href="https://i.sstatic.net/dq0W2.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/dq0W2.png" alt="enter image description here" /></a></p>
  <p><a href="https://i.sstatic.net/Hxt5j.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/Hxt5j.png" alt="enter image description here" /></a></p>
  <p>So I assume this a permissions issue with my setup? What permissions are required for a logged in user be filtered by and see the appropriate layout?  If I change the group I'm in and reload the page, it swaps between Default and Elevated, as I assume it should. I have admin privileges on Civi, but most users do not.</p>
  <p>I logged in as a colleague who also has various admin privileges but is NOT a member of any the four groups and she gets the Elevated label displayed... But, as I say, if I change my group membership, the label change works... Yet I am the Uber admin for Drupal and CiviCRM?</p>
  <p>Can someone explain how this is supposed to work!  There must be a combination of Drupal and CiviCRM privileges going on here, or possible weird caching issue?  (I am clearing caches regularly on the command line though!)</p>
  
Tags: <contact-layout-editor>
Title: Contact layout not behaving as expected
ThreadText: # Contact layout not behaving as expected
  
  (Asked by: username_0 on 2022-11-02)
  
  I am testing Contact Layout and I have what I think is a permissions issue to see the layouts. We use Drupal 7.92 and CiviCRM 5.54, Contact Layout is v2.1.1.
  
  I have installed Contact Layout and have created a single additional layout called Elevated. The Elevated layout is a clone of the system fallback, with just the addition of the Demographics block:
  
  [![enter image description here](https://i.sstatic.net/ue4m7.png)](https://i.sstatic.net/ue4m7.png)
  
  The Display Preferences exclude the Demographic block for all users and this is rightly (I believe) reflected by the System Default layout.
  
  If you are a member of one one of four ACL groups, I want you be able to view (if you have permission) Individuals, of any contact subtype, with the addition of the Demographics block:
  
  [![enter image description here](https://i.sstatic.net/qqSTw.png)](https://i.sstatic.net/qqSTw.png)
  
  This works perfectly when I personally log in as a user that is a member of one of those groups.
  
  [![enter image description here](https://i.sstatic.net/2CGod.png)](https://i.sstatic.net/2CGod.png)
  
  The issue is it does not fall back if I log in as a user that is not in one of those groups - the Demographic block is still displayed. Also, I do not see the Layout labels,
  
  [![enter image description here](https://i.sstatic.net/dq0W2.png)](https://i.sstatic.net/dq0W2.png)
  
  [![enter image description here](https://i.sstatic.net/Hxt5j.png)](https://i.sstatic.net/Hxt5j.png)
  
  So I assume this a permissions issue with my setup? What permissions are required for a logged in user be filtered by and see the appropriate layout? If I change the group I'm in and reload the page, it swaps between Default and Elevated, as I assume it should. I have admin privileges on Civi, but most users do not.
  
  I logged in as a colleague who also has various admin privileges but is NOT a member of any the four groups and she gets the Elevated label displayed... But, as I say, if I change my group membership, the label change works... Yet I am the Uber admin for Drupal and CiviCRM?
  
  Can someone explain how this is supposed to work! There must be a combination of Drupal and CiviCRM privileges going on here, or possible weird caching issue? (I am clearing caches regularly on the command line though!)
  
  **Tags:** contact-layout-editor
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_0 on 2023-07-14. Score: 0 | Accepted answer
  
  The 'fix' on my particular set up was to give 'View' permissions to the Group that was allocated to see that layout. It might be because we are quite locked down, but the code was failing to list the group or groups that were allocated to this layout (see my comments above)
  
  I tested this by adding another plain group (i..e non ACL etc) called testLayout and adding this group to the Contact Layout. So now any user in either one of these groups should be able to see the said Contact Layout. When I added a user to the testLayout group, they were unable to see the Contact Layout, but when I gave View permissions to the testLayout group for that user, it all worked fine.
  
  So I am not sure if this is working as intended, but that has been the solution that I'll be looking at implementing after a bit more testing. Fortunatley, the permissions are layered for me so that people (staff group) have permissions to View the people already in the Team leaders group, as these people are also in the Staff group as well.
  
  It does seem odd though - I would have thought the code would just need to get a list of all groups regardless of who was logged in for this particular check (the code states it is to check for missing groups)
  
  
  ---
  
  ### Answer by username_1 on 2022-11-02. Score: 1
  
  So far as I know, it's not as complex as you're suggesting. It's not using ACL's or CMS permissions, just Civi Groups. The readme says:
  
  > * The "Show" option can specify a contact type, e.g. if a layout is specifically designed for Organization contacts rather than Individuals.
  > * The "To" option can restrict a layout to be visible to only certain logged-in users (e.g. show one layout to your volunteers and another to your staff).
  > * When a user views a contact, the first layout in the list which meets the "Show" and "To" criteria will be shown.
  > * If no layout matches the criteria, the default system layout will be used.
  
  I'm not sure what you mean by 'not seeing the layout labels'. The two following screenshots show the layout labels (or is that showing what you expect to see and aren't?) What happens if you switch to a different theme to rule out any Shoreditch oddities? Are there any javascript errors in the browser console?
  
  I've just tried this on dmaster and the system default fallback works as expected when not in a group with a non-default layout.
  
  ==edit==
  (It's easier to read here than in a comment)
  
  The layout is determined by [CRM\_Contactlayout\_BAO\_ContactLayout::getLayout()](https://github.com/civicrm/org.civicrm.contactlayout/blob/master/CRM/Contactlayout/BAO/ContactLayout.php#L16) which calls [checkGroupFilter()](https://github.com/civicrm/org.civicrm.contactlayout/blob/master/CRM/Contactlayout/BAO/ContactLayout.php#L16) to filter the layouts based on the contact's groups.
  
  If you have `cv` installed you could check what results you get for your colleague:
  
  `cv ev -U admin 'print_r(CRM_Contactlayout_BAO_ContactLayout::getLayout(CID, UID));'`
  
  Replace 'CID' with the contact id of any individual.  
  Replace 'UID' with the contact id of your colleague.  
  If you don't have a CMS user called 'admin' replace that too.
  
  If you get nothing returned, they should see the default layout.
  
  Are there any errors in your errorlog?
  
  > **Comments:**
  > **username_0**: I have been all through the readme and taken a look on Github.  I've also tried turning Shoreditch on and off.  The question is what dictates that a user actually gets to see the Contact Layout label.  I was showing what I would expect to see - logically, you will either see the layout you are entitled to see and the associated label for the layout, or, you will fallback to see the Default Layout and again, the associated label for that layout?  I am not seeing that for a certain class of user and so that is my question - it must be my set up in some way.  
  > **username_1**: See edits to answer  
  > **username_0**: Thanks Aiden, I'll go back to look at this and try to debug it using CV. Clearly not my lucky month as importing contacts seems to have broken now...!  
  > **username_0**: It has been a while but revisiting this as I'd love to get it working.  I recreated this using an out of the box CiviCRM install with generated data so I had users and groups.  Created a single layout called Elevated and it all worked flawlessly, falling back to the System Default.  I used the call via cv to CRM_Contactlayout_BAO_ContactLayout to see how it all worked (thanks for the tip).  However, it still fails to work like this on my system.  When I log in as a user who is not part of the group I've set for that, cv correctly shows what amounts to a null return, but it does not fall back?  
  > **username_0**: Just to add to my comment above, when I run the cv call on a user that is in the single group that can see this test layout, it correctly shows the layout name, the arrays of data displayed and the array of the groups that user is part of to see this layout data. I did manage to get it to work by using an intermediary group.  I created a copy of system default, and set the group to be our main staff group.  So this is a pseudo fallback as all staff are in this group and it correctly displays the limited data, again, the cv call displays the correct data arrays  
  > **username_0**: Hi Aiden - sorry for the continual comments.  This drove me mad so I've gone through this with the debugger (and now found a buried error message in the logs I missed...) The issue appears to be that the logged in user cannot 'see' the group - it fails on line 66 of ContactLayout.php when the call in line 61 to get the Group ID returns an empty array.  It logs with 'Cannot filter on nonexistent group'.  So this is my setup in some way, but it must be a bug? Now to understand what is locked down to stop non admin users operating properly.  
  
  ---
  
  