Permission and Visibility Handling
VISIBILITY MANAGEMENT
In Deepser it is possible to manage the user visibilit on the entities through two additional systems: Roles and Groups.
The Roles allow you to manage visibility vertically, preventing the access access to entire modules (Service, CMDB, CRM etc.) or areas (System submenu) of Deepser.
The Groups instead allow to manage the visibility in a horizontally.
On them is based the visibility, for example, of:
- Types of Service
- Visibility of individual Operations (through group rules)
- CMDB classes
- Types of Contacts
- Any standard grid in Deepser
- Visibility or possibility to modify fields in Form Templates
- Email Notifications (notifications to entire groups)
PERMISSION MANAGEMENT
You can configure specific rules for each group to manage the permissions that users have on Deepser entities.
The Permissions on which the rules can be defined are the following:
| Permission | Explanation |
| CREATE | Indicates whether the user can create records for a given entity. Normally, the conditions in this case are simply true or false or indicate whether a user can create that record. |
| READ | Indicates whether the user can view the details of records for a given entity. In this case, you can define custom expressions to filter visibility on certain record types. For example, we can define that users in a group can display Service Operations, but only those of a certain Service Type. Or we can define the scenario where a user group can only display the Service Operations assigned to the users in the group. |
| UPDATE | Indicates whether the user can edit records for a given entity. In this case, you can define custom expressions to filter the change for certain record types. For example, we can define that users in a group can modify Service Operations, but only those of a certain Service Type. Or we can define that a user group can modify only the Service Operations assigned to the users in the group. |
| DELETE | Indicates whether the user can delete (physically delete) records for a given entity. In this case, you can define custom expressions to filter the deletion for certain record types. For example, we can define that users in a group can delete Service Operations, but only those of a certain Service Type. Or we can define that a user group can only delete the Service Operations assigned to the users in the group. |
| GRID | Indicates whether the user can view records, in the grids, for a given entity. In this case, you can define custom expressions to filter the display for certain record types. For example, we can define that the users of a group can display in the grids only the Service Operations assigned to the users of the group. With this permission you can filter “upstream” the queries made by Deepser’s grids, filtering them for each specific user group and separating the visibility of your service records for individual teams. |
To configure permissions from the group configuration menu access the Rules tab.
A list of any rules already configured for that group will appear.
From here you can add new rules or remove already defined ones.
By clicking on the + button the form for adding a new rule will appear.
The form fields have the following meaning
| Field | Meaning |
| Model | Model on which to define a rule/permit. |
| Type | Type of permission for which define the rule: Create, Read, Update, Delete, Grid. |
| Expression | PHP scripting area where you can define the rule by code. |
| All | This option enables permission (Type), to all members of the current group, on all model entities. |
| Assigned to User | This option enables permission (Type), to all members of the current group, on all entities of the model (Model), of which the User is the Assignee User. |
| Assigned to User Groups | This option enables permission (Type), to all members of the current group, on all entities of the model (Model), which have the current group as the Assignee group. |
| User is Requester | This option enables permission (Type), to all members of the current group, on all entities of the model (Model), of which the User is the Applicant. |
Note1: if a group has no rules configured for some models then that group has read / display / write / delete privileges on all records of those models. For this reason it is always good to set the permissions within the groups whose privileges you want to restrict.
Note2: If a user belongs to several groups, which have different rules, the most restrictive one is applied, case by case.
