Disable element

See also: Enable element, Form elements

Actions – Abstract

The Disable element action deletes the 'Active' option for the linked Target element at runtime.

The Disable element action deletes the 'Active' option for the linked Target element at runtime. This option must be set for an element to be effectively enabled (see note below). An element for which the 'Active' option is not set is always effectively disabled. It does not accept any interactions (accept focus, change value, etc.) and is considered 'valid' without checks (required field, Validators). In general, an effectively disabled element also visually signals this state by appearing 'greyed out'.

images/download/attachments/189432943/image-2024-10-7_15-49-30-version-1-modificationdate-1728308970873-api-v2.png

  • The action can only be selected under Action type if a Target element is linked.

  • The 'Active' option is available for all Form elements.

NOTE

  • The Target element is always effectively disabled at runtime by the Disable element action.

  • If a Target element of the type Element containers is disabled, then all direct and indirect child elements are also effectively disabled. If these are themselves 'set to enabled', they are then regarded as latent active.

  • Because an effectively disabled element excludes all interactive access, settings for the 'read-only' option that affect the element or a parent container are irrelevant with respect to the Target element.

Example

In a form for entering employee data, the input fields are organized by category in a Tab panel element.

Depending on the Role of session, certain tabs should be enabled or disabled at runtime so that the information contained in them is only available to a limited group of users without having to configure a separate variant of the entry form.

Runtime example:

images/download/attachments/189432943/image2020-6-18_10-9-40-version-1-modificationdate-1728308773467-api-v2.png

  • The basic data on the 'employee' is available to all users, but is always write-protected in the form, since a different system is used for this information (including the 'Employee ID').

  • The 'Organisation' and 'Qualifications' tabs may only be viewed and, if necessary, edited with an 'administrative' role. Otherwise, they appear disabled and 'greyed out' (as in the image). They cannot be selected for display.

Configuration:

images/download/attachments/189432943/image2020-6-18_10-13-52-version-1-modificationdate-1728308773470-api-v2.png

  • For each tab that should be 'conditionally accessible', a separate behaviour like the one displayed here has been configured.

  • Since the crucial Role of session cannot be changed while the form is open, the Triggering event Formulardaten geladen is used.

  • The Behaviour type Association criterion matched checks one or more Association criteria. In the example, the only thing of interest here is whether the Role of session has an 'administrative character'. The selection of the relevant roles determines the association criterion.

  • Under the Actions on 'true', no actions are necessary, because the tab is set to 'enabled' by design.

  • Under the Actions on 'false', the action Disable element ensures that the linked Target element (the tab) appears 'greyed out' if the logged-in user is not using any of the privileged roles.

NOTE◄ The Tab panel element always displays the content of the first visible tab when the form is opened. If it is effectively disabled, it will appear greyed out. In the given scenario, disabling the first tab (Employee) would therefore not prevent 'read access' to the contained data. Only for the following tabs, which would first have to be selected at runtime for their content to be visible, 'read access' is also prevented by disabling them. A more effective data protection ensures that the tabs are hidden by Hide element, if necessary.