Check type

The screenshot on the right shows the rule configuration for an 'association criterion' (see Association criteria):

• The only rule configured is a Check type of the 'User' (User) Type.

• A reference to the 'User' type that is usually selected appears below the Check type rule in the configuration.

• Downwards from the Check type, a rule would only be executed due to the AND link with the Check type if there is a reference object in the data context that corresponds to the type 'checked'.

The screenshot on the right shows an OR junction with two instances of the Check type, which allows two alternative types – 'User' (User) and 'GuestUser' (GuestUser) – as alternative reference objects:

• In this configuration, a reference to the 'Interface > User' (IUser) type, to which both types checked above belong, automatically appears below the link.

As shown in the screenshot on the right, the type 'Interface > User' (IUser) could also be selected directly in a single Check type if both Users and Guest users are accepted as reference objects for the data context.

►IMPORTANT◄ This configuration is only equivalent to the previous one if the OR junction (above) covers all types that the 'Interface type' (here: IUser) brings together.

The screenshot on the right initially shows another OR junction with two instances of the Check type, which combines the 'User' (User) and the 'Role' (Role) types as alternatives.

• Below the rule (at the bottom of the screen), the reference to the 'Entity' (Entity) type appears, to which the two checked entity types belong together with all other entity types.

• Within the Entity property rule that follows in an AND junction, the dropdown for field selection only offers the fields that are assigned to the type 'Entity' (Entity) as the overarching data model for all entity types.

►NOTE◄ The Check type does not convert the reference object available at runtime into the checked type (here: 'Entity'). At runtime, there is therefore always a reference object with its specific type (e.g. 'user' or 'role') and all fields. Even a Check type on 'Entity' (Entity) instead of the OR junction would not change this.

►NOTE◄ In order to be able to select fields that the 'Entity' type does not contain via dropdown, another instance of the Check type could be temporarily inserted below the OR link, in which the relevant type (here: 'User' or 'Role') is then selected. After the field selection for both types, this additional Check type can be removed again.

In the screenshot on the right, the Entity property rule has been configured so that either the 'username' (username) or the 'Role name' (roleName) field is used as the check value (left).

The ‘role’ is brought into play via the Default value resolver if the username field returns 'No value' ($null). This is always the case if a 'role' exists as a reference object, as the data model does not provide a username field for this specific type.

►NOTE◄ As can be seen in the screenshot, the Combobox elements in the Object property resolver only display the selected internal field name (roleName, username) and not the associated localization. Both fields are not defined for the 'Entity' type. Therefore, there is no localization and also no type hint for the return value, which should be String, where the default value 'Object' now appears. If you enter the field names (username, roleName) as free text in the Combobox element of the Object property resolver, you get the same result.

The screenshot on the right shows how the configuration from the previous example can be made cleaner, more transparent and even more robust with two instances of the Input object (type safe) resolver:

• Before each access with the Object property resolver, an explicit reference to a specific type is established. In this configuration, the Input object (type safe) resolver implies a 'type check’ against the selected Type: If the input value passes this check, it is considered the return value. Otherwise: 'No value' ($null).

• The Input object (type safe) resolver also works in a similar way to a Check type with regard to the configuration context: The selection for the Type influences the type hint and the lookup function for the concatenated Object property resolver as desired, so that associated fields including localisation appear in the dropdown and the type hint (here: String) matching the selection is displayed for the return value.

<Type selection>(required)

The object passed corresponds to the type <Type selection>. The selection of a type is required.

<Type selection>(optional)

The passed object is a list that does not contain any object that does not correspond to the selected Type. The selection of a Type is optional. Without a selection, entries of any Type are accepted.

►NOTE◄ The test condition sounds a little complicated, but was formulated in this way with the following special cases in mind:

• A list with objects of different types only passes a check without <Type selection> or if a less specific ('parent') Type is selected, e.g. 'User > Interface' for a list containing Users and Guest users.

• A list without entries passes each check type with the option Is collection of independent of a <Type selection>.

<Type selection>(required)

The passed object corresponds to the Type <Type selection> OR no object was transferred BUT the context (e.g. an overview) refers to the object type.

As a Type hint, the entityClass variable is evaluated, which is automatically filled with a 'class' (see Static values) depending on the context.

Example in the context of an overview for Users:

<core:Storage xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:base="SCM.BASE" xmlns:core="CORESYSTEM">
   <data>
      <entry>
         <key xsi:type="xsd:string">entityClass</key>
         <value type="base:User" xsi:type="ClassValue"/>
      </entry>
   </data>
</core:Storage>

►NOTE◄

If a Custom action event is triggered by an event action (Dispatch action event), then, unlike other variables, the entityClass variable is not transferred to the associated execution context, but is determined specifically for this context based on the transferred object. If the value resolver for the Entity in the configuration of the event action refers to a Variable for which there is no value at runtime, the parameterization of this value resolver determines the 'type reference' (via the entityClass variable).

Example:

• In the context of an event handling that reacts to the custom action event triggered by this configuration, the 'type hint' (via entityClass variable) also refers to the 'user' (User) type if the variable 'newUser' does not contain a value ($null).

<Type selection>(optional)

The transferred object is a list that does not contain an object that does not correspond to the <Type selection> type OR no object was transferred BUT the context provides clues for the transfer of a list.

►NOTE◄ The 'Check type hint on empty value' explicitly does not refer to the <Type selection>. Without a specific object, it is therefore only possible to determine unspecifically whether the entityClass variable has a type that is considered a list.

Example:

• This check type is considered to have been passed if a list containing only Users is transferred as the input object.

• A list without entries passes the check, even if it is not of the 'User' (User) Type (see also notes on the second case above). The Check type hint on empty value option has no influence on this because a list without entries is passed as the input value and not 'No value' ($null).

• However, the Check type hint on empty value option is relevant if no list is passed but the context indicates a list.

• This is the case, for example, if the entity for a Custom action event is defined by a Rule list resolver with the Resolve all as list option, which does not return any matches as a result at runtime:

     

  • • In the example, a Create list resolver bundles Users as entries in a list, each of which is provided via a Variable (creator, modifier).

      • The Custom action event 'Send Email' (SEND_EMAIL) should be used to notify all listed persons, provided they are not the logged-in user.

        • The concatenated Rule list resolver in the value configuration for the Entity 'suppresses' list entries that refer to the User of session by 'ID' (id).

          • If both variables (creator and lastModifier) refer to the User of session, the Rule list resolver does not return an empty list ([]), but 'No value' ($null).

          • For an event handling that is triggered by the 'Send Email' and whose Check type is configured as above (Type 'User', Check type hint on empty value selected, Is list of selected), this means that:

            • The return value 'No value' ($null) does not correspond to the Type ('User'), but it is considered an 'empty value'. As the Check type hint on empty value option is checked, the type hint is decisive.

            • The type hint (see also the value of the entityClass Variable in the context of the triggered event) is 'List' (List) because the Resolve all as list option is selected in the Rule list resolver.

            • The Check type is considered passed because the input value is empty and the type hint is to be checked and this type hint is a 'List' (List), which matches the selected Is collection of option.

              • The selection for the Type within the Check type ('User') is irrelevant if only the type hint is checked because there is no value.