Tips for discovering and setting Permissions

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:

ability.act.GroupSupervisor
view.menu.Groups
view.menuitem.CoverageDetails
view.screen.AddGroup

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
  • Basic
  • Messaging
  • Subscriber

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.

NOTES

  • 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.

xMatters Reference

JDN-1305 Originally created by Don Clark

Have more questions? Submit a request

0 Comments

Please sign in to leave a comment.
Powered by Zendesk