When starting to customize ITSM applications is easy to arrive at one point where it is important to differentiate between users, for privileges or different workflow behavior. Two main approaches appear: to use support groups or ARS permission groups. The first solution is easy to administrate from Contact Management forms, but the groups appears in the menu fields (like the incident’s assigned group), which can be undesirable. Second solution provide you more control, but force your administration to be done at the User form, since these permissions can’t be granted from the Contact Management forms… until now.

In this post I will show you how you can allow the administration of these custom permission groups from the CTM:People form for ITSM 7.x versions (and probably others).

How ITSM manages groups

ARS doesn’t understand of support groups, application permissions, company restrictions or functional roles. It only understand of permission groups. So, the Contact Management application (forms starting with CTM) translates all those elements into permission groups. For instance, when you assign John Doe to the VMWare support group, ITSM codifies the support group into an internal permission group, like 1000000234, and adds this user to this support group. If you go to the user form and see the group list, you will see a lot of groups that are named with numbers. Each number represent one support group, company restriction or other ITSM permission elements. The rationale behind this is related to possible name collisions in the permission groups. Assigning them a number, guarantees no duplicates.

All elements work in that way, that is, codified with a group named with a number. All, except application permissions. Application permission list is closed, since it is not configurable. When you deploy the Incident Management application a series of permission groups, like Incident Master or Incident User, are created. Since there is no need to code these permissions with numbers, because the possible names are controlled by the application developer, the permission groups are named exactly equal as the application permission. For instance, when we grant John Doe with the application permission “Incident User” at the CTM:People form, the system adds its user to the permission group named “Incident User”, the same name.

The approach

Let’s return to our objective: We want to create permission groups and allow admins to grant or revoke them to user through CTM:People, without customization. A way to achieve it is my proposed approach: use the application permission concept and add our “Application permissions”.

The best way to explain it is with an example. At Lilonti, a new requirement has arised. Not all users are allowed to close incidents, only the ones marked as “Incident Closer”. So a new permission group is added and users with this permissions can close incidents. If not included in this group a filter will raise an error when trying to close an incident.

With this example in mind, we want to allow admins to grant or revoke the “Incident Closer” permission to users through the CTM:People form. When an admin wants to add this permission to a user, he will go to the People form, click on manage application permissions and when clicking at the menú, a new category is present: Lilontli, under which there is the Incident Closer permission.

To achieve it we need to configure the list where the ITSM stores the information of the application permissions, and add or custom application permissions. The form is “LIC:SYS-License Permission Map”. Enter in this form and we will see a warning.

This message warms us that the contents of this form are vital. If we change or delete a request in this form, we can broke the application permission system, disallowing you to give this permission.

We will only add new requests. We set the new mode and populate the form with these values:

The result:

After saving. All its done. Go to your CTM:People form and try to add this permission to a user.