Run as
Event action – Abstract
Temporarily changes the current login context for one or more event actions.
The Run as event action temporarily defines an alternating login context (with the characteristics user, role, company) for the execution of a block of event actions.
Characteristics not explicitly specified in the configuration are taken from the previous login context. The login context originally goes back to either the current interactive session or a base LobsterDataLoginRequest defined by the interface. However, the previous login context may take into account former uses of Run as, if they are still applicable in the context of the current use. On one hand, Run as can be used to cascade within the same event handling by 'nesting' (see example below). On the other, the alternating login context also applies to events that are triggered, for example, via Dispatch action event in the Run as block. This allows a cascade of Run as event actions, which may adjust the login context incrementally to span different Event handling.
The alternating login context affects the following aspects during the execution of the event actions in the Run as block:
Access permissions (depending on the role used or the interaction of ownership/company and Company authorizations).
Return values of rules and value resolvers that directly refer to the session parameters 'user', 'company' and 'role':
Data directly corresponding to these in the return value of Session information.
Assignments for the fields 'Owner' (ownerId), 'Created by' (creatorId) and 'Last modified by ID' (lastModifierId) when creating entities (see following note).
►NOTE◄ In contrast to create, when entities are changed, the original login context will always be applied if the 'Last modifier ID' field (lastModifierId) is filled in. However, the alternating login context applicable in the context of the Run as event action is still decisive for the prior check of the access authorization for the modification.
CAUTION
The following aspects are explicitly not affected by the alternating login context in an Run as event action:
Locale: The language of the original logon with which the current client session was actually started, unchanged as Current locale.
Default time zone: Optional settings for the 'default time zone' are only taken into account by the user account and/or company account of the original login (with the status at the time of login!).
As soon as the processes triggered within an Run as block have been completely processed, the context automatically reverts to the previously valid login context.
Configuration
The User override, Role override, and Company override parameters can optionally be used to selectively override deviations from the previous login context by static assignments. In the above example, the role and company are overridden while the user is kept from the previous login context.
When configuring, only the users, roles and companies for which there is at least read access within the session are available for selection. If the selection in an existing configuration refers to a target that is not available in the current session, it will appear as 'hidden', as shown above for the Role override parameter. The existing value can be kept unchanged, replaced by one of the effectively selectable options or even deleted. On the other hand, it is not possible to first deselect and then reselect a 'hidden option' within the same editing session.
►NOTE◄ Unlike an interactive login process, the Run as event action not only omits password entry but also the following checks for the effectively applicable alternating login context:
Whether the account selected in the User override parameter is 'Active' (see Users) – i.e. available for interactive login – is not checked.
Whether a company or role is explicitly assigned – i.e. available for interactive login – to the user effectively combined with it via the 'Companies' or 'Roles' field (see Users) is not checked.
In the Run as block below, the Event actions parameter can be added via the 
icon (see upper screenshot).
Example
An event handling should check during the 'creation' (see Common action event) of business objects of the Orders type whether the reference number specified in the reference attribute 'Receipt No.' is already 'on file' in the customer group of the parent company 'Xflow AG'. Depending on whether an order is classified as a duplicate of an already created order, specific further steps are taken, which in the given context can only be reliably executed with the permissions of the 'Super user limited' role.
It is important to bear in mind that the currently registered company, at whose instigation a new order is to be created, does not necessarily have the read access to all orders that may be competing with regard to the 'Receipt No.' required for this check. In the given example, this should only be guaranteed for the parent company ('Xflow AG'), from whose perspective the evaluation must therefore be made.
|
In the example on the right, the Run as event action is used to cascade in two stages:
|
|
