Access determination – in case of conflicting Role privileges and conflicting Page Layout privileges
This blog aims to discuss the situation where there are conflicting Role privileges and on top of that if there are conflicting Page Layout privileges, how does the system determine the privileges that finally get assigned to the user
More details about Access Control can be found in Bernd’s blog https://blogs.sap.com/2015/07/02/blog-series-access-control-management-basics-of-access-control-and-business-roles/
Question: If I have conflicting privileges for multiple roles assigned to the same business user, how does the system determine what privileges to assign?
Roles and Access: If a user is assigned two business roles; one granting display only access and another granting edit access then edit access takes preference and user will get edit access to the transaction.
Question: How do Roles and Page Layouts work in tandem, especially if there are conflicting privileges from multiple assigned roles
The explanation below is geared towards answering these questions:
Based on the access rights assigned, the system first determines if the logged in user get access to the content. Eg: Role 1 grants Read access while Role 2 grants Edit access to the same object. As explained above, the Edit access takes preference hence the user can edit the object. Now, going one level deeper, if only a part of the object can be edited, then you can control it via Page Layouts
Taking an example, if there are 2 user groups that have edit rights to the objects, BUT should be allowed to edit only a subset of fields or their combinations, then, you can have 2 roles –both allowing Edit Access, but 2 different Page Layouts with defined combinations of read only fields. Which PL should get assigned to which Role can also be controlled by another (list) field which is the Instance Type for a BO.
Page Layout 1(VintestRestrictedPL): Field F1 is read only, Field F2 and F3 are editable
|Field||Condition||Layout||Role||ReadOnly ?||Visible ?|
Page Layout 2(VintestPLEditRestrictedFacet2): Field F2 is read only, F3 not visible, F1 is editable
|Field||Condition||Layout||Role||ReadOnly ?||Visible ?|
User Tara is assigned to the role VintestOppCOntrolFacet1
User Kamala is assigned to the roles VintestOppCOntrolFacet1 AND VintestOppCOntrolFacet2 (Conflicting roles)
In the example, if the field VintestRestricted has a value True, then Page Layout VintestRestrictedPL gets assigned to Role VintestOppCOntrolFacet1, else the master is assigned. VintestRestrictedPL doesn’t allow the edit of F1. Edit of Field 2 and 3 though is allowed
Similarly, if the field VintestRestricted has a value True, then the second Page Layout VintestPLEditRestrictedFacet2 gets assigned to Role VintestOppCOntrolFacet2, else the master is assigned. VintestPLEditRestrictedFacet2 doesn’t allow the edit of F2. But, Edit of F1 is allowed and F3 is hidden
Business User Logs In:
A) If user Tara logs in, and an Opportunity has the VintestRestricted value set to True, then the PL VintestRestrictedPL is determined based on her singular access to the role VintestOppCOntrolFacet1. Hence, F1 should be read only for her, F2 editable and F3 Editable as well B) User Kamala logs in and accesses the same Opportunity with the Restricted Value set to True
The reason for the above is, that Kamala was assigned 2 roles that conflict each other
F1: Role1 had F1 as Read Only, Role 2 had it as Editable: Rule: If at least one of the roles disallow the Edit rights, it prevails. Hence F1 is read only
F2: Role1 had F2 as Editable, Role 2 had it as Read Only: Rule: If at least one of the roles disallow the Edit rights, it prevails. Hence F2 is read only
F3: Role1 had F3 as Visible, Role 2 had it as hidden: Rule: If at least one of the roles make the field Invisible, it prevails. Hence F3 is invisible
|Field||Property||Role1||Role2||Role1 & Role2||Reason|
|F1||Read Only||Read Only||Editable||Read Only||Since Role 1 makes it read only|
|F2||Read Only||Editable||Read Only||Read Only||Since Role 2 makes it read only|
|F3||Visible||Visible||Hidden||Hidden||Since Role 2 makes it hidden|
Some basic principles:
- Page layouts can be assigned to roles based on an Instance Type – eg: Restricted field in the above examples.
- It is also possible to combine conditions: Eg: If an Opportunity is Won and custom Field x = ABC, then assign PL1 to Role1. Now, since only ONE instance Type field can be used to control the PL assignment, you can create another custom field which can be updated based on the values of the two fields. You can then use this combined field as the Instance Type field
- If somehow a user is assigned multiple business roles and there are conflicting privileges -> eg: Role1 has the field F1 as read only, whereas Role2 doesn’t. In that case:
- If the Read Only or Mandatory property is enforced by any of the assigned Page Layouts of the applicable roles, it prevails.
- Similarly for the visibility property: If the field is made invisible in any of the assigned Page Layouts of the roles applicable for the logged in user, it is set to Invisible. This holds true for fields, facets, sections groups – wherever you have the visible property exposed
- To avoid this conflict, it is highly recommended that we evaluate why one would need to assign multiple roles with conflicting privileges
- Beyond this, if you want to control the behavior for different roles by allowing Save or Not, that can be done by PDI. Page Layouts do not give privileges on the Edit button, nor does PDI. But using PDI, you can throw error messages while doing a Save. 1611 also gives you APIs to use for reading roles assigned to the logged in user