Business Rule for sys_user_has_role is not triggered

[Sebastian R_]

Hi guys,

I want to log every role assignment/unassignment to a user into the system log. Therefore I wrote a business rule for table sys_user_has_role.

The Business Rule is working correctly if I assign a role to a user.

 The problem is that the rule is not triggered if I assign a group to the user which inherits a role (e.g. Group Field Services) which is then assigned to the user.

My first suggestion was a setWorkflow(false) in the insert script. But unfortunately I couldn´t find that piece of code. It is not the business rule "Group Member Add" (I deactivated it and the roles are still inserted).

Can someone confirm this and can find that piece of code?

My questing is related to another unanswered question: Business Rules not being triggered on Insert, for the User Role table
https://community.servicenow.com/message/904287#904287

[Sebastian R_]

My BR does not appear, because it´s not even triggered. As far as I know it would only appear and be skipped, if it doesn´t match my conditions.

I did a little bit of research and found my corresponding Insert-SQL Statement.

If I understand this correctly, it´s triggered by a Java-Class and not by a BR etc.

Can anyone confirm this? Maybe some SN developer?

[Jaskaran Walia]

Hi,

Did you find the reason why this was happening? I am now facing same issue i.e. when user is given role by adding to group, it is not triggering my BR and same when a role is inherited from another role.

[Sebastian R_]

Hi,

unfortunately not. I think there is something working in the background where we have no access to.

A bad workaround could be a scheduled job...

Regards

Sebastian

[Jaskaran Walia]

Thanks for getting back to me. I have raised HI, if they provide any help or solution to me, I will let you know.

I am going to try to see if I can run BR on sys_user_grmember table and achieve what I want. If this doesn't work, then like you suggested, a scheduled job to do the work!

[Jaskaran Walia · Accepted solution]

Hi,

ServiceNow team came back with an answer!

Essentially what they said is as part of "Contextual Security Manager" plugin, when a user is added to a group, they insert records in sys_user_has_role table at database level and suppress any BR to run against this table! Weird design but that's what it is.

Reply from HI:

Referring to the Contextual Security Manager documentation: https://docs.servicenow.com/bundle/jakarta-platform-administration/page/administer/roles/reference/r_ContextualSecurity.html?cshalt=yes this plugin prevents duplicate entries with Contextual Security: Role Management V2. This plugin is active on your instance. As per the documentation, roles inherited from other roles are added as individual entries in the User Roles table [sys_user_has_role], potentially causing one role to have duplicate entries. Contextual Security: Role Management V2 eliminates these duplicate entries and prevents future duplicates. Its the same case as adding groups with the same roles containing it, without the plugin, the roles will be added to the sys_user_has_role record of the user and duplicate records will appear. With the plug installed, adding a group that contains roles that is already on the user's role list will not add a duplicate entry in the sys_user_has_role table, instead, the inheritance count is incremented. This plugin is activated on your instance. The description is of this plugin states: "Role Management Enhancements: prevent duplicate entries in sys_user_has_role for inherited roles, based on the value of the inh_count column" The documentation explains further: Contextual security and roles You can grant roles to users or groups. However, after installing the Contextual Security Manager, the roles field on the user record is no longer checked and no longer appears on your user and group forms. Instead, you must add roles to the Roles related list instead of to the user or group record. Solution Proposed/Investigation Summary: If the Contextual Security Manager plugin is activated on the instance, the BR's on the sys_user_has_role are not getting executed when the roles being added is coming from a Group. Only the BR's from sys_user and sys_user_grmember tables gets executed when adding a Group to a user record. The plugin prevents having duplicated roles in the sys_user_has_role table. When a particular role is already existing in the user's role list, and the role gets added again via the Group, the Inhertance count is incremented to reflect how many times that role was granted to the user. For your implementation, a possible workaround can be to add the BR on either the sys_user(after Insert/update) or sys_user_grmember which will go through the roles of the user.