Roles can be assigned to a user in several ways:
- directly.
- to a group, the user belongs to. In this case, all users of this group also have this role.
- to a parent group that includes the group the user belongs to. In this case, all users of the parent and child groups also have this role.
- via a parent role.
The information about roles, groups, and their interconnections is stored in the following tables:
| Table | Description |
|---|---|
| Roles (sys_role) | A list of the roles created in the system. |
| User Roles (sys_user_has_role) | A list of the users and their roles. |
| Groups (sys_group) | A list of the groups created in the system. |
| User Groups (sys_user_group) | A list of the users and their groups. |
| Role Contains (sys_role_contains) | A "many-to-many" table, interconnecting parent and child roles. |
| Group Contains (sys_group_contains) | A "many-to-many" table, interconnecting parent and child groups. |
| Group Roles (sys_role_group) | A "many-to-many" table, linking roles with groups. |
The above tables are interrelated. When you change a record in one of them, the changes can occur in other tables. For example, when a user is added to a group, a record is created in the User Groups table. All group roles will be assigned to the user by creating new records in the User Roles table. The relationships of these tables are shown in the following diagram:
User Roles
The User Roles (sys_user_has_role) table stores information about the user roles that were:
- assigned directly.
- gained through groups.
- gained through parent roles or groups.
To get the list of the available records in this table, navigate to User Administration → User Roles.
Example
John Doe has several roles:
- He is a change manager. This role was assigned to him directly by his manager.
- He is an incident manager. He got this role through the Incident Managers group because he is a group member.
- He is an impersonator. He got this role through the impersonators group (which is included in the security admins group).
If you exclude John Doe from the Impersonators group, he will lose the impersonator role, and the relevant record will be deleted from the User Roles (sys_user_has_role) table.
The following example shows the multiple roles for one user:
There can be two identical roles: one is set to the user manually, and the other is inherited (Inherited = true). If a user is a member of several groups that give them the same role, the value of the Inheritance count field increases.
Groups
Group records are stored in the Groups table. A group may have a connection with a role. Such records are stored in the Group Roles table.
When adding a user to a group, a relevant connection record is created in the User Groups table. Then, the user obtains the group role, and a corresponding record appears in the User Roles table.
When deleting a record from the User Groups table, the user loses the group role.
Role Inheritance
Roles can be inherited in various ways.
- They are inherited from a parent group. To do so, add a record to the Group Contains table, specifying a parent group. All child group members get the roles of the parent group.
- They are inherited from a parent role. To do so, create a record to the Role Contains table with a child role. All users who have the parent role also inherit the child role.
- They are inherited from a group role. If the role is defined for the group within the Group Roles table, the users inherit all roles of the group they belong to. To add them to the group, create a record in the User Groups table.
The other way around also works: when you unbind a role and a group (you delete the record from the Group Roles table), all the group members lose this role. When adding a child role for a parent role, the users with a parent role get a new child role, and so on.
The level of inheritance does not matter. For example, a specific parent group has parents, and its child group has, in turn, their descendants. In this case, parents get all the roles of their descendants.
