See also: Set flag, Working with flags

Actions – Abstract

The Unset flag action resets the flag specified by the Flag name in the context of the form, so that the behaviour type Check flag, that refers to this flag, returns the check result 'false'.

images/download/attachments/189433333/image-2024-10-9_10-5-11-version-1-modificationdate-1728461110998-api-v2.png

The Unset flag action resets the flag specified by the Flag name in the context of the form, so that the behaviour type Check flag, that refers to this flag, returns the check result 'false'.

If the flag in question was set before the action was executed, the triggering event Flag changed is triggered, so that other behaviours can be executed within the form.

►NOTE◄ Linking an element has no effect on this action.

Example

The basis for the following example is the use case described in more detail in the example for Set flag. This involves displaying an 'account statement' for a specific customer in a portal, which compares invoices with any incoming payments.

The source data from a Tuple search (Form designer) behaviour is transferred by Populate element data into a Repeatable element, whereby criteria for a customer's poor payment behaviour are checked. If these apply to any of the invoices, a flag with the name 'paymentAlert' is set via Set flag, and a warning symbol is displayed in the form header (see below).

The original example does not allow the flag 'paymentAlert' to be unset at the form's runtime, because the form is opened modally for a specific customer account and the payment behaviour is evaluated once. The life cycle of the flag ends when the form is closed anyway. An extension is now provided to allow the source data – e.g. after booking an additional incoming payment – to be called again by clicking on a Button (see below) if the form is already open. Then the flag must be unset.

Runtime example:

images/download/attachments/189433333/image2020-7-3_11-11-38-version-1-modificationdate-1728456372327-api-v2.png

Configuration:

images/download/attachments/189433333/image-2024-10-9_10-10-59-version-1-modificationdate-1728461459304-api-v2.png

The behaviour for loading the source data is configured to the newly added Button ('Reload data for 'Customer account') as shown on the left:

In addition to the previously used Form data loaded, the Triggering event Click is added as a trigger, since the same thing should happen when clicking the button as when opening the form.
As a Behaviour type, the Tuple search (Form designer) is left unchanged (collapsed in the image, because details are not relevant).
Under the Actions on 'true', two additional actions are now inserted before the Populate element data action, which fills the Repeatable element container displayed as a 'grid', and which should restore the original state of the form:
- Unset flag resets the flag with the Flag name 'paymentAlert'.
- Populate empty element data clears existing content from the Repeatable element container.

images/download/attachments/189433333/image-2024-10-9_10-14-44-version-1-modificationdate-1728461684048-api-v2.png

To ensure that the warning symbol is also hidden again when the flag is reset, the behaviour for the Image/Icon element concerned must be adapted as shown on the left:

As a Triggering event the Flag changed can still be used, because it triggers when setting and unsetting.
As a Behaviour type, Check flag is now used, because the changed status of the flag with the Flag name 'paymentAlert' should allow a case distinction with specific actions.
Under the Actions on 'true', i.e. when the flag has been set, the Image/Icon 'BAD' is made visible as before by the Show element.
Under the Actions on 'false', i.e. when the flag has been uneset, the same Image/Icon element is now made invisible by Hide element.

►NOTE◄ As shown here, the Triggering event Flag changed can also be used to respond to the flag change at other positions within the same form. In more complex use cases, different effects can be configured for the 'decentralized' flag depending on the change of state. This may be clearer and easier to maintain than providing a long list of actions in a single centrally created behaviour (e.g. in the form element). On the other hand, the sequence in which actions are executed can be specifically influenced within a central behaviour.