Has permission
Rule types – Abstract
Purpose: Is considered 'passed' if at least one of the Permissions statically defined in the configuration of the rule is present in the context of the Role of session.
The Has permission rule is considered 'passed' if at least one of the Permissions statically defined in the rule's configuration is present in the context of the Role of session.
Each individual permission can be noted, either absolutely (e.g. /businessObjects/shipment/workingState/create) or relatively (e.g. update or workingState/create) (for details see 'Configuration').
►IMPORTANT◄ The rule only checks whether the Role of session grants a 'role permission' and not, for example, whether this permission can also be applied to a possibly existing specific reference object in the context of the Company of session (taking ownership and Company authorizations into account)..
Configuration
|
The Permissions parameter is a Text field that supports line breaks. Each text line defines a specific permission check, which is evaluated as either 'passed' or 'failed'. The rule as a whole is considered to be 'passed' if at least one permissions check is considered 'passed'. A single permission check can be noted either absolutely (by a 'path' starting from the root of the permissions tree) or relatively (by a 'path' starting from the permissions node for a given context). A permissions check in the relative notation can only be 'passed' if the data context provides a specific entity as a reference object or at least a type reference (entityClass) (see Check type).
The Select Button opens an editor (see top right) that can be used to interactively select elements of the permissions tree. When Apply is clicked, the existing selection is converted to text format for Permissions and inserted into the Text field. The entries can be edited afterwards, e.g. to convert absolute paths into relative ones. |
The following example shows three absolute paths followed by three relative ones:
|
absolute paths for system tools:
|
|
An absolute permissions path always starts with a slash ('/') and refers to a specific permission or a specific node in the permissions tree. The permissions check for an absolute path is considered 'passed' if the Role of session grants the specific permission or at least one permission below the addressed node. |
In the example above, the first line addresses the permissions node for the File manager, which bundles various permissions together. The following two rows concern specific permissions for the Search builder and the 'Create' of general business objects of the 'MEMO' type. |
absolute path for a predetermined entity type:
|
|
A relative permissions path always starts with the name of a node that should address either a specific permission or a permission node that exists in the context of the entity type determined at runtime. The permissions check for a relative path is considered 'passed' if the Role of session grants the specific permission or at least one permission below the addressed node. ►IMPORTANT◄ The relative notation is effective only in conjunction with appropriate entity types. In the context of portals and data objects that are not entities, only absolute permission checks are effective. |
In the example above, rows 4 and 5 concern specific permissions ('Read', 'Delete') for an entity type arbitrary from the configuration point of view. The last row defines a check that is considered 'passed' if this entity type is authorized to 'print' tracking state entries in any print format. ►NOTE◄ The tree display on the right is only intended here to schematically reflect the criteria for the relative permissions checks in the example. The editor cannot be used directly to output relative paths without reference to an entity type. However, absolute paths can be created and then converted to relative ones. |
relative path for an 'arbitrary' entityClass:
|
CAUTION
Example
Simple example
An association criterion should be considered 'passed' if the logged-in user has permission to choose the Current locale via the settings for the session (Change locale).
Configuration:
|
The rule for the association criterion is configured as shown on the right:
►NOTE◄ The system does not require a configurator to know the complete permissions tree and the internal names of all contained nodes by heart and to type them in without error when configuring a Has permission rule. The Select Button opens an editor instead (see below), which can be used to specify absolute permissions paths by making a selection in the tree instead of entering text. |
|
|
The editor for selecting Permissions contains – as usual (see Roles) – a search function that can be used to filter the possibly quite extensive content in a targeted way. In the example on the right, after entering the text 'Localization' in the search field, only a manageable number of permissions nodes are visible, so that the permission searched for to Change locale can be quickly and reliably detected and transferred to the Text field of the configuration via Apply. |
|
More complex example
An association criterion shall be considered 'passed' whenever the Role of session in the context of any entity...
... EITHER the permission to 'Show XML' AND at least one of the permissions 'Show details' OR 'Update' provides,
OR access granted to the Search builder AND 'read' allowed for the entity type.
Configuration:
