Elevated Permissions
Overview
Elevated user permissions (EUP) are data card-specific permissions: they are a way to grant users additional permissions for certain data cards, based on the value of certain reference attributes on the data cards. The additional permissions are configured as normal ESM roles under the Permissions folder tree pane.
Note:
By default, the elevated user permissions are disabled in ESM. The functionality can be enabled by setting the elevated.permissions.enable platform setting to true.
Elevated user permissions can be configured separately for each template. The configuration is done in the Edit template view, as shown in the screenshot below:
Note:
- Elevated user permissions can be configured only when the template has one or more reference attributes whose target is the ESM user template (either directly, or via a reference chain). Otherwise the Elevated user permissions configuration options are not visible in the Edit template view.
- Attributes must have an attribute code and cannot have a reference to any other target than ESM user template to be displayed in the Elevated user permissions configuration options.
- If the user does not normally have the permissions for neither the template nor the folder of the data card, elevated user permissions must be used to grant both permissions – if only the folder permission is granted, the user cannot see the template, only an empty folder.
- Create permissions are meaningless for elevated user permissions. This is because the elevated user permissions are always specific to existing data cards, so they can never grant permission to create new data cards. For a suggestion on how to handle data card specific create restrictions with elevated user permissions, please see the Example 2 below.
Example 1
Consider the following use case: Incident template has a reference attribute named Support person that points to the ESM user template. You would like to give support persons (ESM users) permissions to edit certain fields on those Incident cards that are assigned to that person, but not on any other cards. This cannot be done by using the normal folder-based permissions. The Elevated user permissions functionality, however, can be used to achieve this.
First, go to the Permissions folder tree pane and configure a new role which has exactly those extra permissions that we want to grant to the support persons. The role is named, e.g., Request support person.
Note:
Unlike with most roles, no users are usually added to this role.
Second, in the Edit template view for Incident template, elevated user permission is configured by selecting the attribute Assigned to and the role Request support person. (All roles in the system are shown in the drop-down menu.) This phase is illustrated in screenshot below.
When the configuration is saved, the extra permissions for support persons on those Service requests which are assigned to them become effective immediately.
Note:
In the Edit template view, the Save button must be clicked before any changes made to the Elevated user permissions are effective.
Example 2
Sometimes it would be desirable to have a separate folder for support requests, where the users could create support requests themselves, and they could only see their own support requests. This cannot be achieved by elevated permissions only – the normal role of the user needs create permission for the request folder, and create permission always includes an unrestricted read permission as well. However, this use case can be implemented by using data card listeners in addition to elevated user permissions.
The solution is to use two folders for support requests. First, a folder to where all users can create support requests is needed (in this example, “New support requests”). And second, a folder from where the users can read the support requests is needed (in this example, “Existing support requests”). In addition, a data card listener needs to be added to the support request template. The function of this listener is to move a data card from the “New support requests” folder to the “Existing support requests” folder immediately when it is created (so that in practice the folder for the “New support requests” is always empty). And finally, elevated user permissions in the support request template need to be configured so that the user can read, update and delete her own data cards in the “Existing support requests” folder.
Table of Contents