After adding a new Entity property rule, it appears as shown on the right:

• The value configuration for the check value (left) contains an Object property resolver for which no field is selected.
  
  

• The Equals compare type is predefined.
  
  

• The value configuration for the compare value (right) appears empty.

If there is a type reference for the reference object for the context of the Entity property rule, for example because a Check type is provided within an AND Junction ‘above’, a field can be selected immediately in the Object property resolver (after expanding).

In the example on the right, a ‘company account’ (see Company accounts) is expected as the reference object, so that – as the screenshot shows – the ‘Metatype’ (metaType) field is found when ‘type’ is searched for.

After selecting the ‘Metatype’ (metaType) field, its data type – the Company meta type defined as a dynamic enumeration – is adopted as the type hint for the compare value because the Equals compare type provides for this.

There is still no value configuration for the compare value, but in contrast to the first screenshot, the ‘+’ symbol indicates that a value resolver is proposed when the value configuration is expanded, with which a Company meta type can be selected as a static value.

The screenshot on the right shows the Dynamic enumeration resolver proposed for the Company meta type based on the check value type, which returns two results in the dropdown for the entered search text ('a').

Unfortunately, the Dynamic enumeration resolver only allows a single selection. If different ‘metatypes’ are defined as acceptable with the same Entity property rule, the Equals compare type must be replaced by the In list compare type.

►NOTE◄ Alternatively, it is possible to ‘juxtapose’ several instances of the Entity property rule in an OR Junction.

A change of compare type must be initiated by clicking on the menu icon within the hexagon shape:

CAUTION As can be seen in the previous screenshot (right), the value configuration for the compare value is overwritten when the Matchers changes.

For the In list resolver, a Create list resolver is proposed for the compare value configuration, with which any number of entries can be defined.

Unfortunately, the data type of the check value is not evaluated as an indication of the level of the list entries, so that the appropriate Dynamic enumeration resolver is not automatically suggested here.

Instead, Any dynamic enumeration must be used to select specific values for the Company meta type enumeration.

►NOTE◄ If all selected enumeration values come from the same enumeration, this appears as a type hint for the return value of the Create list resolver (see screenshot on the right).

By default, the In list compare type is considered passed if the check value is contained in the list provided as a compare value. The list therefore becomes a positive (whitelist). If the list needs to function as a negative list (blacklist) instead, the logic must be ‘reversed’:

This is made possible by the not menu item in the context menu for the Matchers selection.

This Entity property rule exists for companies whose Company meta type is not ‘Company’ (COMPANY) or ‘Group’ (GROUP).

►NOTE◄ Instead of reversing the logic for the Matchers, this could also have been done for the Entity property rule as a whole (see screenshot on the right).

This is made possible by the ‘not’ ribbon button in the context menu for editing the rule, which can be opened by clicking on the menu icon in the top left-hand corner of the surrounding rectangle.

The screenshot on the right shows the ‘negated’ Entity property rule. The ‘!’ indicator appears as an icon at the bottom of the rectangular shape and as a prefix in front of the text in the title bar (‘!Compare...’).

►NOTE◄ The screenshot on the right compares the appearance of the two variants for the negation in the context of an OR Junction (which makes no logical sense due to the redundancy).

• The first variant is textually more ‘readable’:
  metaType not(in list)

• The second variant visualises the negation more clearly.
  NOT: (metaType in list)