Roles
As explained in the Users chapter, the effective access rights for a user depend on the combination of Role and Company accounts implicitly assigned or explicitly selected for a specific session.
The purpose of the Role in this context is to categorically grant and, more importantly, to deny certain permissions.
To be effectively applicable, permissions involving data objects (e.g. to update user accounts) need to be granted by the role as well as appropriate access to the particular data object (e.g. a specific user account). By default, access is limited to data objects owned by the company. Access to data objects owned by other companies requires Company authorizations. The only exceptions to this rule are data objects without an owner and specific master data objects (e.g. the 'role' itself), for which ownership is disregarded by definition. In both cases, all companies have full access to the data object and only role restrictions apply.
The context of a Company defines the 'operating range', in which the permissions granted by the Rrole can be effectively exercised – as far as these permissions depend on company access (through ownership or authorization).
Permissions for roles and Company authorizations are largely structured alike, which make intersections (see the example below) easy to recognise and efficient to manage.
However, role definitions also contain plainly functional permissions (e.g. access to administrative tools), not subject to authorizations between companies. Conversely, Company authorizations may refer to permissions that are not referenced in role definitions.
Example
A user registers for a session with reference to a role, which grants 'Read' access for shipments but denies 'Update', 'Create' and 'Delete'. The company assigned for the session is explicitly authorized to not only read but also update shipments owned by another company. Effectively, the user may only read shipments by that company. Updating shipments is denied regardless of ownership.
In very simplified terms, the role permissions and company authorizations are intersected, as far as is relevant for both contexts.
As shown in the image, a 'Show details' permission is only featured for roles, not authorizations. Implicitly, this permission applies for all shipments the user is authorized to read.
Role overview
Roles are managed via the Role overview menu item by combination of a list and details form:
The list (1) shows existing roles as far as accessible in the current session.
Details for a specific role are shown in the Role (2) and Permissions (3) tabs.
Depending on the permissions granted, the user may click New in the ribbon to add a role or select an existing role from the list (1) to Copy, edit and Save or Delete.
The Role name (4) serves as a plain text identifier for the role and must be unique in the system. Optionally, a Role description (5) can be added, to characterize the purpose of the role.
Tip: The role name can be translated via the localization (bundle: 'rolename', key: name of the role). The bundle 'rolename' may have to be created first.
Like a user account, a role can be set to Active (6) or not. Inactive roles cannot be used to log in. Users without an active role are therefore denied access to the system.
All roles (except the 'Super user' role) must refer to a Parent role (7). This relation between roles adds up to a role hierarchy, organized by the following principles:
The role assigned during login is called the Role of session. This Role of session is restricted to read access by definition. It cannot be changed or deleted.
Access to roles is limited to the hierarchy down from the Role of session. Besides the Role of session itself, the list of roles will only show roles that are direct or indirect children of that role.
When a new role is defined, the parent role must be picked from the same list of roles. Therefore, the new role can only become a part of the given hierarchy below the Role of session.
References to roles inaccessible form the current session, are represented with label 'Hidden role'. As long as a user account or role definition refers to 'Hidden roles' it cannot be saved.
Roles can only refer to permissions granted by the parent role. Typically, only a subset of the permissions of the parent role is granted. See the following section for further important details.
►NOTES◄ The 'Role' object belongs to the few master data objects for which ownership is disregarded. Access to roles depends only on the Role of session related to the role hierarchy. Since the Company of session is irrelevant, there are also no permissions for roles in Company authorizations.
Permissions
The Permissions tab is used to define the permissions to be granted for the role. Three different Modes (1) are supported:
|
Mode |
Permissions |
|
'All' |
The role grants all permissions covered by the parent role. |
|
'All but consider owner restrictions' |
The role grants all permission covered by the parent role, except those of the type 'Ignore owner restrictions'. |
|
'Custom' |
Based on the permissions granted to the parent role, a subset of permissions can be defined by a tree view (see screenshot). |
Details on 'Custom' mode
In 'Custom' mode permissions are represented as elements in a permission tree (2) that can be toggled between 'checked' or 'unchecked' to grant or deny the specific permission. The tree features 'group elements' in multiple levels, which can be checked and unchecked to grant or deny all permissions featured in a branch.
For each group element one of the following three status symbols is shown:
A 'check' symbol indicates that all permissions below in the branch are granted.
An empty space indicates that all permissions below in the branch are denied.
A 'shaded' space indicates that there is a mix of granted and denied permissions below in the branch.
►IMPORTANT◄ The tree view only contains permissions (and related group elements), granted according to the current definition of the parent role. The logic for status symbols described above only considers the elements actually featured in the tree. This rule also applies for trees showing search results (see below).
By entering a string into the Permissions (3) search field, specific permissions or group elements can be identified by name. The search is started by pressing 'Enter' and reduces the tree to branches containing at least one match. The tree representing the search results can be used to check/uncheck permissions and group elements.
To restore the full tree, delete the entry in the search field (3) and press 'Enter' or click the x-symbol, which replaces the 'looking glass' next to the search field when search results are displayed in the tree view:
►WARNING◄
When the scope of permissions for a role is reduced, these permissions are effectively denied for any direct or indirect children (roles). Consequently, corresponding elements disappear from the permission tree view for those roles, but are not deleted. If the definition of a child role contained is previously granted for any of the affected permissions, that information remains latently stored in the role definition unless the role is updated. If the scope of permissions for the parent role is extended again or a more powerful role is assigned as a parent, any 'latent' permissions for the child role become effective again immediately.