0

I've been trying to grant access to the Configure ribbon (specifically the Template strip) in Content Editor to a role which currently can't see it. I've been trying to do this through read permissions in the Core database. I've applied them to the targeted role and to various roles and sub-roles which comprise it; I've applied them to the Template strip, the Configure ribbon, and all the elements up and down that part of the content tree up to the Content level. The Access Viewer indicates all the roles I've edited should be able to view all the items I've edited, but whenever I try to log in with a user account the ribbon remains invisible. (I do have one test account which can see it, but this account has all the same exact permissions and roles as those which can't, which just leaves me confused.)

Details: I'm working in Sitecore 9, focusing on /sitecore/content/Applications/Content Editor/Ribbons/Strips/Configure/Template and /sitecore/content/Applications/Content Editor/Ribbons/Ribbons/Default/Configure (I couldn't tell for sure what each does and figured they might interact).

It would appear I'm missing something, or possibly am focusing in entirely the wrong place. Any advice?

2
  • It looks like you have denied read permission for either any one of Role or User. You can compare all the applied roles with working and nonworking users to identify gaps. If a user is a member of two roles, one that explicitly grants them an access right to an item and one that explicitly denies them the same access right to the item, they are denied the access right. Commented Sep 8, 2023 at 17:08
  • I've examined all the roles, explicit and inherited, the target user has and assigned them all read permissions. The user still can't see the Configure ribbon. Commented Sep 8, 2023 at 18:47

1 Answer 1

1

To investigate and resolve the issue you can leverage Sitecore Access viewer. It is used to see how your security implementation is manifested by displaying the security permissions in the Sitecore content tree for a selected user or role. Its main purposes are:

  1. To confirm your security permissions are manifested as expected.
  2. To troubleshoot user or role access issues if your permissions are not working as expected.

Access Viewer grid shows the culmination of all of the selected role/user's permissions as realized by the combination of role membership and explicit permissions. Since users rarely belong to a single role we must be able to identify the root cause of permission issues should one role adversely affect another role. Access Viewer therefore becomes the tool to allow you to diagnose permission issues when they arise.

To take this a step deeper, if you are interested in seeing how a user has gained a certain implicit or explicit permission (or for that matter, been denied a certain permission), you can click directly on the permission itself and the right rail will populate with additional forensic information. For example, if you were interested in how the sitecore\ContentAuthor user inherited write access to the Home node, simply click on the write permission in the grid and you will see the right rail reveal additional information:

enter image description here

In this example, you can see that the text in the right rail notes that write access was obtained via explicit item:write access to the sitecore\Author role, a role that sitecore\ContentAuthor is a member of. This statement is reinforced by the image below the statement which reveals that the sitecore\Author role has been granted explicit write permissions on the Home node.

In contrast, by reviewing the Administer privilege of the Home node (a permission the ContentAuthor user has not been granted), the Access Viewer reports that the user does not have this privilege because it has not been granted explicit permission, nor does it belong to a role that grants those permissions.

enter image description here

I know it's not the direct answer but hope this gives enough information that clarifies how you can use Access Viewer and helps you come closer to resolving your issue.

Hope it helps!

1
  • Access Viewer and I are old friends. In this case it's letting me down: it indicates the users who can't see the ribbon have view permissions and should be able to see it just fine. Commented Sep 11, 2023 at 13:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.