Domains do not get assigned correctly if the user is assigned the role through a group assignment.

Steps to Reproduce

  1. Activate the Domain Support - Domain Extensions Installer plugin.

  2. Create a new group (GroupA) and add a role to it (RoleA).

  3. Switch the domain to one of the subdomains (for example, TOP/ACME).

  4. Go to sys_user table and go to user record who is in that domain (acme.itil).

  5. From the Roles related list, click Edit and add RoleA to the user.

  6. Personalize the related list and add the Domain and Domain Path fields.

    Note that they show the domain and domain path of the user (User role record).

  7. Switch to the Group related list, click Edit, and add GroupA.

  8. Personalize the fields and add Domain and Domain path.

    Note that they show the same domain as the user.

  9. Go back to the Roles related list.

    Note that the role that got added through the group (Role A, which has inherited true) is in the global domain. Therefore, if the user in one domain goes to the role record from here, that user is able to see the users in other domain with that role.

    The role that got added through the group also should be in the correct domain as that of the user, but instead, the User role record shows the domain as global.



Write a script to iterate through all the sys_user records and fix the sys_user_has_role.sys_domain values.

  1. Loop through the sys_user records using a GlideRecord query.
  2. For each user, the script can get the sys_domain value from the sys_user table.
  3. Check that the  sys_user_has_role.sys_domain field value for the current user in the loop.
  4. If it is not the same as sys_user.sys_domain field's value, update the sys_user_has_role.sys_domain field value to keep it in sync with sys_user.sys_domain value.
Until you upgrade to a version that includes the fix for this problem, you would have to periodically check whether sys_user domain matches the sys_user_has_role records domain. If not, fix the data via the script and run the script periodically, for example, daily or weekly via a Scheduled Job.
  • If your instance is on V1 Role plugin(Contextual Security/com.glide.role_management), the issue should occur only when someone is editing the sys_user_role_contains records.
  • If your instance is on V2 Role plugin(com.glide.role_management.inh_count), the sys_user and sys_user_has_role will be in sync only after this fix. Most likely all other operations on roles would cause this issue.

IMPORTANT: Do not remove/delete the sys_domain column from sys_user_has_role table as a fix to this issue. That is NOT the workaround for this issues. 

Related Problem: PRB997761

Seen In

There is no data to report.

Fixed In


Associated Community Threads

There is no data to report.

Article Information

Last Updated:2019-05-21 11:37:00