Set current working state
Event action – Abstract
Purpose: Attempts to assign a specific Working state as 'Current working state' to the current reference object.
The Set current working state event action attempts to assign a specific Working state to the current reference object as the 'current working state'.
Values can be assigned to the Reason (reason) and Realization time (realization) for the working state entry created in the event of success.
Success depends on the following factors:
The reference object must belong to an entity type that qualifies as a 'working state owner'. (see Working state (Event actions)).
For the role claimed in the applicable logon context (see also Ausführen als), the 'working state/create' permission must be guaranteed for the entity type of the reference object.
If Working state matrix are applicable to the current context, they must allow switching from the current working state of the reference object to the allowed one selected in the Working state parameter.
Special features for ownership and company authorizations for working state entries
If a working state is successfully assigned to a reference object via the Set current working state event action, then the Company of session from the applicable logon context (see also Ausführen als) is considered the owner of the created working state entry by default.
Access control via ownership and Company authorizations is only effective for individual working state entries if they are addressed directly, e.g. by a Search. Access rights for the entity registered in the entries as 'working state owner' do not play a role.
Based on a specific 'working state owner', on the other hand, access control for individual working state entries on the basis of ownership and Company authorizations does not play a role. As long as access to the 'working state owner' exists and corresponding role rights are available, the 'working state history' therefore always shows all historical entries and therefore a complete status history.
For the creation of a working state entry, there is effectively no access control based on ownership or Company authorizations that directly affect the working state for an entity type. Event handling that can identify any entity suitable as a 'working state owner' via the Input object (type safe) value resolver, for example, can always create a working state entry for it via the Set current working state event action. Access rights for the entity are not required for this, nor is a release for creating a working state.
Configuration
The event action must be executed in the context of a suitable reference object ('working state owner').
|
|
Example
The workflow for Orders imported into Lobster Data Platform / Orchestration via an interface requires that they are transferred from the automatically assigned Working state 'Imported' (IMPORTED) to one of the working states 'Released' (RELEASED) or 'Rejected' (REJECTED) in the course of an incoming inspection, depending on the inspection result. In the input form for the orders to be checked, a button 'Check' is offered, which triggers the following event handling via a Custom action event with the data of the order.
The event handling should request the check result from the user via a User prompt:
The standard text 'OK' signals the release of the order.
Any other input will be interpreted as a reason for rejection.
It should be possible to cancel the check by not entering any text or pressing the 'Cancel' button.
Runtime example:
Configuration:
|
An event handling for a Custom action event 'Check' uses a Typprüfung to ensure that the event was triggered in the context of an order. The Actions on passed rule are configured as shown on the right. Within an If then else event action, the three possible cases for the outcome of an incoming inspection are linked with specific actions for this purpose:
►NOTE◄ In both cases, the explicit assignment of a Realization time is omitted, so that the generated working state entry is 'updated' at the time of execution. |
|
