Role-on-role permissions control how roles act on themselves and other roles, and they specify the user-data a given user is allowed to see in the xMatters interface.
There are three main types of role-on-role permissions:
- How the current role can act on other users who have the same role
- How the current role can act on users with other roles
- How users with other roles can act on the current role
Role-on-role permissions are defined on the Roles Details page.
- Click the Admin tab.
- On the Permissions menu, click Roles.
- Click the name of a role for which you want to view role-on-role permissions.
- xMatters displays the Role Details page.
The following example displays the role details for a Group Supervisor:
The three main sections on the Role Details page define the permissions types of the selected role (Group Supervisor, in this example) related to all other roles. The following table provides further details about each type of role-on-role permission:
|Permissions within this role||
Controls what this role can do to other users with the same role (what Group Supervisors can do to other Group Supervisors).
All users who have the Group Supervisor role will be able to take these actions on other Group Supervisors. For example, Group Supervisors have the ability to see other Group Supervisors in search results for messaging, groups, and other places.
If no permissions were selected, then Groups Supervisors would not be able to take any actions on users with the Group Supervisor role (unless those users had another role that could be acted upon by a Group Supervisor).
|Permission on other roles||
What this role can do to other roles (what Group Supervisors can do to Company Supervisors, Full Access Users, Standard Users, etc.).
If you are configuring permissions for the Group Supervisor role, the permissions specified here define the actions that Group Supervisors can take on other roles in the system.
For example, Group Supervisors have permission to see (but not edit) the custom fields, attributes, and devices of Company Supervisors, and see them in search results for messages, groups, and other places.
|Permission other roles have||
What other roles can to do this role (what Company Supervisors, Full Access Users, etc. can do to Group Supervisors).
For example, Standard Users only have permission to "use" Group Supervisors (that is, see them in searches, etc.). Full Access Users have full permission over Group Supervisors (they can assign others as Group Supervisors, and edit, delete, and manage their subscriptions).
This section of the table should only be used as a convenient summary of the permissions that other roles have on the current role. If you want to change the actions a given role can take on another role, use the other role's Role Details page to define its "Permission on Other Roles" settings.
The column headings of the Role Details page define the types of actions that roles may take on one another:
Controls the ability to assign other people to this role (typically not touched).
Provides the power to see and edit other users' custom fields, attributes, and devices (very important).
|Delete person||Grants the ability to delete existing users.|
Lets a user see other users' custom fields, attributes, and devices, but not edit them (important).
|Use person||Enables the ability to see other people in search results for messaging, groups, or other places, but not drill in to see their custom fields, attributes, or devices (most important).|
|Manage subscriptions||Allows you to assign subscriptions to others.|
Some of these setting take precedence over others. For example, if Edit Person is enabled, then View Person or Use Person have no effect. Supervisors always have the ability to view, edit, and delete their employees - there's no need to try and replicate the hierarchical structure of your company exactly by assigning employees their actual supervisor in the supervisor field.
Many users in xMatters are assigned more than one role. When users are assigned multiple roles they are not limited by the permissions of their "lowest access" role; they have permissions from all their roles. For more information about the types of roles used in xMatters, see Roles.