Delete later
See also: Save changes later
Event action – Abstract
Purpose: Flags an entity for deletion at the completion of the current transaction.
The event action Delete later creates a flag for deletion for the current reference object within event handling.
When the transaction is completed, the entity in question is then deleted if it still exists.
►NOTE◄ For a reference object that has never been saved, executing Delete later usually has no effect. In the context of an input form that provides a volatile input object directly after executing 'New' or 'Copy', this object cannot be 'discarded' by calling an event handling with the event action Delete later.
Definition of the reference object
In the simplest case, the current reference object is the entity determined by the event handling data context.
However, there are also event actions (e.g. Execute with or For each loop) that can temporarily override the current reference object at runtime. The configuration of the event action provides a defined block of event actions to be executed in the context of an alternative reference object. At runtime, the alternative reference object is considered the current reference object for these event actions, as can be traced via the value of the variable entity, if applicable. Within such an action block, the event action Delete later also refers exclusively to the entity temporarily defined as the reference object.
Within an event action that provides an alternative reference object, Resolvers can generally be used to define a specific reference object:
The data item of an entity can possibly be resolved directly via a Variable or an Object property.
Often the value resolver Input object (type safe) must also be used, e.g. to retrieve the data item of an entity starting from a reference to its ID (id) (e.g. Linked entity type or Linked line item type).
►IMPORTANT◄ The Delete later event action should be executed only with independent entities as the reference object and not, for example, with attributes or items of business objects. No corresponding check takes place at runtime, and executing the event action for a related object that cannot actually be stored (interactively) on its own may lead to unexpected results when the transaction is completed.
Flag for deletion
The flag for deletion takes into account the applicable logon context (company, role, user) at the time of execution of the Delete later event action, which may be defined as temporarily different from the current session at runtime by the Run as event action.
If the Delete later event action is executed multiple times within the same transaction for the same reference object, the flag only takes the logon context of the last execution into account.
This login context is the deciding factor for checking for permissions to delete the reference object.
The fact that the deletion is not immediately triggered by executing the Delete later event action also causes the following effects:
If a rollback (by an Abort or a 'real' process exception) is triggered after executing Delete later for the same transaction, the 'delete later' is omitted and the entity in question is maintained.
The time of execution of the event action for a specific reference object within the same transaction is irrelevant. Until the transaction is completed, there is access (inside and outside the transaction) to the reference object to be deleted.
Repeated execution of the event action for the same reference object within the same transaction has no effect unless different logon contexts are used (see above).
Execute the deletion
The deletion flag is not taken into account until the current transaction is completed. If one of the flagged reference objects was not deleted by the transaction, an attempt is then made to delete it explicitly. If this attempt fails because an error message occurs, the transaction as a whole is considered a failure and a rollback is performed. In this regard, the following aspects must be considered:
The logon context applicable in the course of the flagging (see above) must have the authorization to 'delete' the reference object.
Executing the Delete later event action in the Try block of a Try/Catch actor does not result in catching errors that occur 'later' (when deleting).
►NOTE◄
Since deleting objects is generally not supported in the context of Tests, the Delete later event action has no effect whatsoever in test mode.
If within the same transaction for the same reference object not only the Delete later but also Save changes later event action was executed, there are flags for saving and deleting the reference object when the transaction is closed. Saving is then completely unnecessary, even in the special case that a 'volatile' reference object is present, i.e. one that cannot be deleted because it has never been saved.
Example
When any entity is deleted, all Documents assigned to this entity should also be deleted automatically.
Configuration:
An event handling for the Triggering events 'Delete' is configured as shown on the right side:
When all relevant documents have been flagged for deletion, the transaction is completed. Only then will the entity passed as the input value of the event handling and all assigned documents really disappear from the database. ►NOTE◄ It is assumed that in the logon context for all relevant documents at least the authorization to 'read' (for the Search (Event action)) and to 'Delete' is given. If the Search (Event action) returns at least one document for which 'Read' is allowed but 'Delete' is not, an error occurs when the action is completed, which triggers a rollback of the transaction. Then the deletion is ineffective for all documents and the entity itself.
|
|
The collapsed Search (Event action) shown above should only be configured as shown on the right:
|
|