iAccessHandler troubleshooting | User_admin cannot edit or add group members to a group containing a role - Support and Troubleshooting

iAccessHandler troubleshooting | User_admin cannot edit or add group members to a group containing a role Issue Users with the user_admin role unable to add to or edit members of a group containing a role? Start here for troubleshooting tips and examples.

To demonstrate, consider the following scenario:

Set up a test sys_user_group sntest that contains the sn_templated_snip.template_snippet_reader role. Created a test sys_user testuser_admin and give this user the user_admin role ONLY. Impersonate sntest , and navigate to the sntest group.

Notice that sntest sys_user cannot write to the sntest sys_user_group. Please note this behavior extends to roles that contain the sample role.

In other words, if the sntest sys_user_group contains the sn_customerservice.esc_fulfiller or the sn_esm_agent role role (which CONTAINS the sn_templated_snip.template_snippet_reader role in its hierarchy), the same applies.

Note the IAccessHandler violation in the ACL evaluation.

Cause This is due to a combination of the Application Administration checkbox on the Templated Snippets sys_store_app, as well as the Assignable by field on the affected sys_user_role record, as shown in the below screenshots and explained by the Restrict access to an application product documentation :

To clarify, when Application administration is checked, the platform must honor what is in the Assignable by field for a sys_user_role. If assignable_by is empty, and application administration is checked, NO ONE on the platform can grant this role.

Resolution This can be very tedious to identify especially when there are multiple layers of nesting. Consider a hypothetical scenario with following role inheritance structure:

With each layer - (and keep in mind certain roles like sn_hr_core.basic contain at least 5 roles that have their own inheritance chain), the number of checks can become exhausting and it is easy to lose count of what has already been checked.

There are in addition two potential criteria that have to be identified in a nested role:

The user running into the iAccessHandler violation doesn't have the role itself. One of the roles in the inheritance chain has 'Application administration' checked - but no 'Assignable by' populated, resulting in no one being able to assign the role. We've created a script to simplify this identification: