Notifications

50 views

Issue

Symptoms


Example:

Group : Customer Support

Roles assigned to this group : sn_hr_core.basic [ assignable by : sn_hr_core.admin ]

1) Impersonate a non-admin user in affected instance. [ Based on ACL, this user is allowed to add members in group 'Customer Support']
2) Navigate to sys_user_group.LIST, and open this group : 'Customer Support'
3) Click the ‘Edit’ UI action to add the respective 'New User' to the group 'Customer Support'.
4) Click on ‘Save’.

Expected Result: 'New User' will be added to 'Customer Support' group.

Actual Result : 'New User' will NOT BE added to 'Customer Support' group.

Release


All

Environment


All

Cause


 
This is due to group : 'Customer Support'  have scoped application roles which can only be assigned by a person who has a particular role. 

In all scoped application roles there is a field called as 'assignable by'

The user who is trying to add this user in the group should have the role present in the assignable by field. 


Resolution


Please add 'role' to the user which is present in the assignable by field of the scoped application role.

Additional Information


This issue was not debugged even when ACL debugger was on, and lead to iAccessHandler

iAccessHandler: An internal system check using hidden source code on the platform.

This is a system security check that you cannot modify. IAccessHandler can grant or deny access to a resource without evaluating ACLs.

If IAccessHandler is ignored, then the ACLs are evaluated. You cannot modify the IAccessHandler checks in any way.

For example, an IAccessHandler implementation is used for access checks on application resources and this cannot be changed. 

Article Information

Last Updated:2019-08-02 20:55:49
Published:2019-01-09