Constraints can be used on top of type validations provided by the base fields described in the previous chapter. The base class BaseConstraint is used as base type and contains shared functionality.

Since fields are usually only validated when there’s change detected, it’s usually necessary to add back references to chain validations.

## DependConstraint¶

When choices depend on each other, you can use the DependConstraint type. The following example makes sslurlonly depend on the sslbump option, since the <reference> tag is needed to make sure when one of the settings changes, the other is validated again too.

<sslbump type="BooleanField">
<Constraints>
<check001>
<type>DependConstraint</type>
<field1>sslurlonly</field1>
</check001>
</Constraints>
</sslbump>
<sslurlonly type="BooleanField">
<Constraints>
<check001>
<reference>sslbump.check001</reference>
</check001>
</Constraints>
</sslurlonly>


## AllOrNoneConstraint¶

Make sure that options are only valid when selected in combination.

## SingleSelectConstraint¶

When options are not valid in combination, you can hook options together so only one of the options can be selected at the same time.

## UniqueConstraint¶

This constraint helps to make sure all items within an ArrayField are unique, such as the following example which makes sure all “filenames” in this set are unique.

<filename type="TextField">
<Constraints>
<check001>
<type>UniqueConstraint</type>
</check001>
</Constraints>
</filename>


## ComparedToFieldConstraint¶

The ComparedToFieldConstraint compares the value of the current field to the value of a referenced field on the same level (for example in the same ArrayField). It is for example used for the rspamd plugin, to ensure that some values are in the correct order. This constraint can be used to compare numeric values.

Example:

<check003>
<ValidationMessage>This field must be bigger than the greylist score.</ValidationMessage>
<type>ComparedToFieldConstraint</type>
<field>greylistscore</field>
<operator>gt</operator>
</check003>


In this example, the valueof the current field must be greater than the value of the field “greylistscore”.

Field values:

 ValidationMessage Validation message (translateable) which will be shown in case the validation fails. type ComparedToFieldConstraint field the other field which we reference operator The operator to check the value. Valid operators are gt, gte, lt, lte, eq, neq

Operators:

 gt greater than gte greater than or equal lt lesser than lte lesser than or equal eq equal neq not equal

## SetIfConstraint¶

The SetIfConstraint is used to make some fields conditionally mandatory. It is mainly used in the nginx plugin for example to choose an implementation type. In general the other field should be an OptionField, but does not need to. In general it is a good idea to hide or show fields which are (not) required by an implementation in the frontend as well to simplify the web interface. Please note: the checked field is intended to be on the same level (for example ArrayField).

Example:

<check001>
<ValidationMessage>This field must be set.</ValidationMessage>
<type>SetIfConstraint</type>
<field>match_type</field>
<check>id</check>
</check001>


In this example, the value will be mandatory, if the field “match_type” has the value “id”.

Field Values:

 ValidationMessage Validation message (translateable) which will be shown in case the validation fails. type SetIfConstraint field the other field which we reference check The value of the other field which makes this field required