This article describes how you can easily discover which Permission controls a given element in the xMatters web user interface. It also provides some tips that you can use to develop your understanding of how Permission names are structured. Note that this article applies to xMatters (alarmpoint) enterprise only.
Roles, Functions, & Permissions Review
IMPORTANT UPDATE: Versions 4.0 patch 9 and 4.1 patch 1 added 'hover over' functionality to the Permissions page in the web user interface. To see a description of a permission, hover the mouse pointer over its formal name (e.g., hovering over action.DeviceAction brings up a tool tip of Can validate Devices).
For the purposes of this article, it is assumed that you already have a clear understanding of the relationship between Roles, Functions, and Permissions (for details, see the latest xMatters installation and administration guide). However, a quick review here will help you understand the content of this article.
Essentially, Roles are collections of Functions; and, Functions are collections of Permissions. For example, xMatters enterprise includes a default Role called Full Access User. In turn, this Role is made up of a number of Functions, one of which is Supervise Groups, which is made up of Permissions that look like the following:
Keep these four permissions in mind as you read through the next section.
Understanding Permission Prefixes
Permissions represent the most granular expression of system access settings in xMatters. And, because access privileges are so flexible, there are many available Permissions - and this can sometimes be overwhelming at first.
However, once you understand the naming convention for Permissions, you will very quickly be able to work with them more intuitively. In general, Permission prefixes have the following meanings:
- ability.act provides the power to carry out a given set of actions (such as those carried out by Group Supervisors)
- view.menu controls access to a given tab (such as the Groups tab)
- view.menuitem controls access to a given menu item (such as the Coverage Details menu item)
- view.screen controls access to a given page and its functionality (such as the Add Group page)
Discovering a page element's associated Permission
Assume that all non-administrative Users in your system have the Role "Standard User". By default, Users who have this Role can modify their Custom Attributes from the Common Tasks panel on their home page. Further assume that you do not want these Users to be able to create, modify, or delete Attributes.
Using trial and error, you could dig through the Role's underlying Functions and Permissions to figure out which Permission you need to remove to take away the ability to work with Attributes. However, you can also try this shortcut: hover your mouse pointer over the element you would like to discover the Permission for, and then check your web browser's status bar for the element's path (you may need to enable your browser's status bar first). The URL will include a .do as part of the path.
For example, if you hover over the Custom Attributes link on the Common Tasks panel, you will see a URL in the status bar that includes AddCustomAttributes.do. Now you know exactly which Permission controls access to the Add Custom Attributes page. Armed with this information, you look at the Standard User Role and discover that it is made up of the following four Functions:
- Alerts Access
Using a bit of logic, you eliminate Alerts Access, Messaging, and Subscriber as unlikely to include the AddCustomAttribute Permission. You then look at the Permissions for the Basic Function and see a Permission called view.screen.AddCustomAttributes, which you remove from the Function's Selected Permissions list. The next time any User with the Standard User Role logs in to the web user interface, they will not see the Custom Attributes link on the Common Tasks panel, and they will not be able to navigate to the Add Custom Attributes page.
- You can also use this Permission discovery shortcut to add a Permission to a Role. Start by logging in as a User who has the ability to see or act on a given element, discover what the .do is for it, and then add it to the target Role's associated Function.
- Changes you make to non-administrative Roles do not affect the Permissions of Super Administrators and Company Administrators. However, be aware that removing or adding a Permission in a Function affects all other Roles that include that Function. In many cases, creating new Roles and Functions will be a better solution than attempting to modify existing Roles and Functions. However, you can still use the Permissions discovery shortcut to help build a list of Permissions that you want a new Role or Function to include.
Quick Messaging Panel changes
The Quick Messaging feature used to be permissioned like any other screen (e.g., view.menu.Messaging, view.menuitem.Messaging, view.screen.QuickMessage) but was changed to a “special” custom message panel when the messaging panels were reconfigured for a previous patch release. As a result, the Quick Messaging Panel inherited the custom message panel security framework, which is Role-based. If you create a custom Role and you want it to have access to the Quick Messaging Panel, you will have to modify the Panel's assigned Roles, rather than changing the permissions for the custom Role.
JDN-1305 Originally created by Don Clark