Examples of conditions

The value must be equal to any of a set of predefined values

Example: assume you only want to show some text when a property is located in any of the following cities: Antwerp, Amsterdam, Paris or Barcelona.

The long way to write this is:

{#property^location = "Antwerp" OR #property^location = "Amsterdam" OR #property^location = "Paris" OR #property^location = "Barcelona"}

The shorter and more readable way to write this:

{#property^location in @list("Antwerp", "Amsterdam", "Paris", "Barcelona")}

The wrong way to write this:

{#property^location = "Antwerp" OR "Amsterdam" OR "Paris" OR "Barcelona"}

The reason the above condition does not work, is that — due to the short-hand comparisons feature — the software will actually interpret this as #property^location = "Antwerp" OR "Amsterdam" = true OR "Paris" = true OR "Barcelona" = true, similar to how the software would interpret a condition such as {#property^location: ...} as meaning “if some value is assigned to this datafield, then show the following text: ….

In other words, because in the wrong example above, for Amsterdam/Paris/Barcelona the comparison misses a second part, the software will implicitly “fill up” this second party with “= true”. Because the words “Amsterdam”, “Paris” and “Barcelona” obviously contain at least one character, these parts will always be true. The end result is that this condition will always be considered true, even when the property’s location is not filled in, and even when the property’s location would for example by “New York”.

The value must not be equal to certain values

Example: assume you do not want to show a certain piece of text for a property located in Moscow or Milan.

The long and probably incorrect way to write this:

{not(#property^location = "Moscow") and not (#property^location = "Milan")}

The above example is probably wrong, because it will also show the piece of text when no value has been assigned to the property’s location, or when the property’s location has been assigned an empty text value. This is probably not what you want. To take this situation into account, you would have to write an even longer version:

{#property^location and (not(#property^location = "Moscow") and not (#property^location = "Milan"))}

This new condition first checks whether some non-empty value is assigned. If so, then it will check whether that value is not equal to either “Moscow” or “Milan”. This works, but is a bit long. This can be shortened to:

{#property^location and #property^location !in @list("", "Moscow", "Milan")}

or even shorter:

{#property^location !in @list("", "Moscow", "Milan")}

Two datafields must have a value equal to some predefined value

Example: a certain bonus is awarded when an employee’s collective labour agreement (CLA) is either nr. 123 or 456, while at the same time the employee’s status must be active or on parental leave.

The double wrong way to write this:

{#employee^cla = 123 or 456 and #employee^status = "active" or "parental-leave"}

The first error is that, due to the short-hand comparison described earlier on this page, the software will actually interpret this as (#employee^cla = 123) or (456 = true) and (#employee^status = "active") or ("parental-leave" = true). This expression will always be true, because any number other than zero (such as 456) and any piece of non-empty text (such as “parental-leave”) will be considered “true” by the software.

The less wrong (but still wrong) way to write this:

{#employee^cla = 123 or #employee^cla = 456 and #employee^status = "active" or #employee^status = "parental-leave"}

This is still wrong, because it is very unpredictable for human beings to remember how this will be interpreted by the software, due to the concatenation of AND and OR. Will the software interpret this as (CLA = 123 OR CLA = 456) AND (status = "active" OR status = "parental-leave)? Or instead as (CLA = 123) OR (CLA = 456 AND status = "active") OR (status = "parental-leave)? Or even in some other way?

There exist “precedence” rules for this, but many people have problem remembering the precedence rules for addition and multiplication of numbers, so even if you remember correctly what the precedence rules are for AND/OR/NOT, the person who comes after you to update your texts will probably make a mistake in the interpretation. In any case, the above condition is hard to read.

A correct solution using parentheses is for example:

{(#employee^cla = 123 or #employee^cla = 456) and (#employee^status = "active" or #employee^status = "parental-leave")}

A shorter version, which drops the concatenation of AND/OR:

{#employee^cla in @list(123, 456) AND #employee^status in @list("active", "parental-leave")}

A “list of texts” datafield must contain a value

Example: a piece of text must be shown when an employee’s fringe benefits (a “list of text” datafield) includes both meals and tuition:

The very wrong way to write this condition:

{#employee^benefits = "meals" or "tuition"}

This not only suffers from the short-circuiting issue described above, but will also result in an error because you are comparing a list of items (i.e., the “list of texts” datafield #employee^benefits) to a single text item (“meals”). For the software, this boils down to comparing apples to oranges, hence the error.

A less wrong (but still wrong) way:

{#employee^benefits = @list("meals", "tuition")}

This will in many cases be wrong, because it will only be true if the benefits include only meals and tuition — i.e. if the list on the left side and the list on the right side are exactly equal and include exactly the same elements. If any other benefit would have been assigned to the employees, then this condition will erroneously become false.

Even when the employee’s benefits consist of only meals and tuition, the above condition may erroneously result in false, when the tuition happened to come before the meals in the datafield, i.e. if the ordering is different. The reason is that list-of-text datafields take ordering into account — after all, in certain contracts, the order of appearance of the elements may be very important.

A correct way to write this condition:

{("meals" in #employee^benefits) AND ("tuition" in #employee^benefits)}

or, somewhat shorter (but also more fancy and probably less readable):

{@is_subset(#employee^benefits, @list("meals", "benefits"))}