Permissions determine which parts of the system a user has access to and what actions they are permitted to carry out within them. They are configured in the user details and user group details on the Permissions tab. This section explains the principles underpinning permissions – what conditions must be fulfilled for a user to gain access, what can be configured via permissions, and how the final set of permissions is determined when an account is a member of multiple groups.
Terms of Access
When working with permissions, it is important to bear in mind that the fact that a permission has been granted does not necessarily mean that the user will actually see the function or record in question. Access is only granted through the combination of three separate mechanisms.
- Global settings determine whether a particular feature is enabled in the environment at all. If a module or feature is not enabled, the permission will not apply and the relevant objects may not even be displayed in the Permissions tab.
- A permission determines what a user is allowed to do with a given record type – whether they can access, create, edit or delete it.
- Data visibility determines which records are affected. A user authorised to edit requests can only edit those requests to which they have access, for example, based on visible companies.
So, if a user cannot see something even though they have the relevant authorization, this is usually because the feature has been disabled in the global settings or the data is not visible. Visibility is covered in detail in the section of the documentation entitled ‘Managing access to data and functions’.
Classification of authorizations
Authorizations are organised into a tree structure by module. At the top level, there are several dozen modules, each forming a separate branch containing its individual components — record types, individual form fields, actions and other permissions. This makes it possible to set access permissions for each module individually, without affecting the others.
The depth of a branch depends on how complex the module is. For simple modules, there are only a few items; for requests or a configuration management database (CMDB), the branch has several levels. Below is an overview of the configuration settings in the permissions tree:
- Access to the module – the top level of the tree determines whether the module is viewed by the user in the menu. This is a prerequisite, as without access to the module, the settings below it will not apply.
- Records – basic operations with module records, i.e. viewing, creating, editing and deleting them. Some modules have multiple record categories; for example, the Configuration Management Database (CMDB) distinguishes between Object Records, Parent Group Records and Object Type Records
- Access to Third-Party Records – extends access to records that the account did not create and in which it does not hold any role, for example, requests from other users. Without this authorization, the account can only work with its own records.
- Access to subordinate records – grants access to records of subordinate users according to the configured hierarchy of supervisors and subordinates.
- Access to records from visible orders – grants access to records linked to orders that are visible to the account. This is available for requests and fulfilments
- Access to fields – individual form fields as separate items, so that a specific field can be hidden or locked. This also includes a common item: User-defined fields.
- Export and import – whether the account is permitted to export the list to a file or import data into the module.
- Special permissions – additional rights in a separate column that cannot be expressed by the four standard permissions (view, edit, create and delete), such as access to internal discussions or sensitive attachments.
- Permissions for individual records – individual authorization or restriction for a specific record, going beyond what applies to the entire module. These are accessed via the cog icon next to the relevant item.
The range of the tree is not the same in all environments. The branches of selected modules are only displayed if the relevant functionality is enabled in the environment. If these functions are enabled, you will see the tree in its full range.
The last two items in the overview and access to fields are covered in detail in the ‘Specific Authorizations’ section of the documentation.
Taking over and priority of permissions
Permissions are inherited. An account takes over the permissions of all the groups included in it, and may have its own custom settings applied directly to it. Two rules apply when combining permissions.
- Permissions take precedence over restrictions between groups – if an account is a member of several groups and a permission is allowed in one group but restricted in another, the permission applies. So, for example, if an account is included in a group of assignees where the authorization is allowed, and at the same time in a group where it is prohibited, the result is that the authorization is allowed.
- Individual settings override the inheritance result – if you need to revoke a permission from a specific account that is set to ‘allowed’ based on its group membership, you set it directly to ‘disallowed’ on the account itself. This overrides the result taken over from the parent application, and the authorization will be denied regardless of what is indicated by the groups.
Setting user and group permissions
Permissions are configured in two places – in the details of a specific user and in the details of a user group. In both cases, the Permissions tab is used for this purpose:
- For a user – Users and Groups → Users → a specific user’s record → the Permissions tab.
- For a group – Users and Groups → Groups → details of a specific group → the Permissions tab.
As permissions are inherited, we recommend setting them primarily at group level and only addressing any exceptions at individual account level. The tab will only become available once a record has been created and saved, as it is linked to an existing account or group. If the record has not yet been saved, instead of the tree structure, a message will appear stating that the permission settings will be viewed once the record has been saved.
Note: Restrictions do not apply to the main administrator’s account; they always have full access. For system groups, permissions are read-only and cannot be changed.