Role of session
Value resolver – Abstract
Purpose: Returns the data of the role for the applicable login context.
The Role of session value resolver returns the role data (see Roles) for the applicable login context.
The following scenarios are distinguished at runtime:
|
Runtime scenario |
Return value of the 'Role of session' |
|
The applicable login context goes directly back to an interactive or Login API authenticated session. |
'Clone' of the role with which the session was started. ►IMPORTANT◄ The flatPermissionNames field, which usually contains a string list with the role permissions, always returns the value null in this 'clone' by definition. |
|
A Run as event action in the direct or indirect execution context of the value resolver specifies an 'As role' to temporarily define the applicable login context different from the actual logged-in role. |
Server-side data set of the role defined in the temporary login context. (incl. flatPermissionNames) |
►WARNING◄ Do not use return values for write accesses!
At the beginning of an interactive session, a clone or 'snapshot' of the data of the role used is created so that its data does not have to be repeatedly retrieved from the server during the session. Since no write access by the user of this session is disallowed for the role used within a session, the created 'snapshot' is not renewed during the session. The Role of session value resolver provides the data of this cloned role in the first of the scenarios described above.
CAUTION
The clone of a existing role should never be used to save changes made to it. Firstly, it does not correspond to the current server-side state if changes from other sessions or login contexts have been received there after cloning. But the fact that all information about role permissions (in the flatPermissionNames field, see above) is completely missing in the clone is much more important.
If the clone of an existing role – e.g. via Save changes later in an event handling – is saved, this role will not have any permissions afterwards.
Therefore, for automated write accesses, the current state of the role should always be retrieved from the server. For this purpose, the 'ID' (id) of the account identified as Role of session can be passed to the Input object (type safe) value resolver.
Configuration
The value resolver ignores the input value and does not use any parameters.
Example
Example: Simple association criteria
Most association criteria based on the Role of session can be implemented easily and transparently with a Role rule, i.e. without the Role of session value resolver.
The Role of session value resolver, on the other hand, is needed to access information from the role's data model, e.g. in an Entity property rule.
As a simple use case scenario, an association criteria is defined to 'take effect' if the role used in the login context has been changed recently (in the last 7 days). If this association criteria applies, a portal can be provided in the menu bar, for example, in order for the user to obtain information about any role changes.
Configuration:
|
An association criteria is configured as shown on the right:
►IMPORTANT◄ The association criteria takes into account the 'clone' of the role that is created when logging in. If a change is made to the role during the runtime of a session, i.e. after this clone has been created, then the association criteria does not react to the changed modification date until the next login. |
|
Example: Check if the role context with 'Run as' is changed
The fact that the 'clone' of the role in question returned as Role of session in an interactive session does not contain flatPermissionNames is used in an event handler for a case distinction that 'recognizes' whether the role in the applicable login context originates in the session or a Run as event action in the direct or indirect execution context.
Specifically, a notification should indicate that a role has been temporarily assigned, even if it is identical to the role used in the 'genuine' session.
|
Within an If then else event action, an Object property rule like the one shown on the right is used to check that the flatPermissionNames field for the Role of session does not have the value null. ►IMPORTANT◄ A comparison with No value is necessary for this check, because the Is empty matcher does not distinguish whether the return value for the flatPermissionNames field is really null or just an empty list ([]). The latter would be the case if no permissions are assigned to a role. While this makes limited sense, it cannot be ruled out. The Show alert (Popup) event action below is executed only if the returned role contains permissions (or an empty list), which is the case only if it is not the 'clone' from a real session. However, if the role in the applicable login context returns to the session, then the case discrimination does not provide for any special measures. |
|
