The Roles menu item can be found in the Main menu via the ‘Administration/Accounts’ menu node, provided there are sufficient permissions.

By default, it opens an overview for the ‘Role’ (Role) entity type, which lists all Roles that the Role of session can access.

• View name: de.lobster.scm.base.security.role::Role|listDetailsWindow

• Menu node name: admin/accounts/roleOverview

Access to Roles is regulated by the permissions for the ‘Administration/Accounts/Roles’ node ((administration/accounts/role).

• The Roles menu item only appears if the permission ‘Show’ (show) is available for Roles.

• In contrast to other entities, only their position in the role hierarchy is decisive for accessing Roles.
  

  • Although an ‘owner’ (ownerId) is formally identified for each entity of the ‘Role’ type, there are effectively no owner restrictions for this entity type.

  • If the Role of session takes owner restrictions into account, there is only access to Roles that belong to the hierarchy downwards from this one because they are directly or indirectly subordinate to it.

►IMPORTANT◄ Write access for the Role of session is not permitted if it does not have the 'Ignore owner restrictions' permission for Roles .

• Without this permission, the ‘Save’ and ‘Delete’ ribbon buttons appear disabled if the Role of session is selected. On the other hand, ‘Update’ is also prevented in the automation context (e.g. via Save changes later ) if it affects the Role of session .

• Even with the 'Ignore owner restrictions' permission for Roles , updates to the Role of session are restricted. Changes to the ‘Parent role’ ( parentRole ) field and to the permissions ( flatPermissions ) are ignored on ‘Update’.

As already described in the Users section, the effective access rights within a session result from the permissions for the Role of session and – if owner restrictions are relevant – the ownership structure and, if applicable, Company authorizations for the Company of session.

The Role of session categorically decides which permissions should always be available and, above all, which are always excluded.

In order for permissions that relate to entities (such as 'Update' for Users) to be used effectively, access by the Company of session to the individual entity must be guaranteed in addition to the basic permission for the Role of session. This is of course only the case for entities for which the Company of session is the ‘owner’. All access to entities owned by other Companies/Clients requires Company authorizations. Special cases are entities to which no owner is assigned and special entity types (certain master data, e.g. also the ‘roles’) for which no ‘owner restrictions’ apply by definition. In both cases, permissions granted by the Role of session can be exercised regardless of the Company of session.

With regard to entity types for which ownership restrictions are fundamentally relevant, the Company of session (via ownership and, if applicable, Company authorizations) determines the scope in which the associated permissions of the Role of session can be exercised.

The permission structures for the definition of Roles and Company authorizations are largely similar, so that the overlaps (see example) can be easily understood and efficiently managed.

However, the role definition also includes purely functional permissions (e.g. access to administrative tools) that are not covered by Company authorizations. Conversely, approvals can occasionally be granted for permissions that are contained in the permission structure of Roles.

Specific example:

• A Role of session is used that allows a user to Read and View entities of the ‘Aircraft’ (Custom entity type in namespace custom) type, but not to 'Update', 'Create', 'Delete' (etc.).

• The Company of session is authorised by another company to not only Read but also Update the data of ‘Aircraft’ entities in its possession.

In this constellation, the user effectively has the following accesses for ‘Aircraft’ entities in the context of the logged-in session:

• The View role permission allows the user to open an overview for the ‘Aircraft’ type.

• Due to the Read company authorisation, the overview lists not only custom ‘Aircraft’ entities (owned by the Company of session), but also those owned by the releasing company.

• The Update company authorisation is effectively ineffective, as the user is not allowed to update custom ‘Aircraft’ entities without the corresponding role permission.

By default, the interactive administration for Roles is based on a combined view (listDetailsWindow), which can be opened via the Roles menu item in the Main menu.

The following screenshot shows the default ribbon (for a role with all relevant permissions), below the default input form with the details of the role selected in the list area (at the bottom).

active

roleName

parentRole

roleDescription

flatPermissionNames[]