SINCE 3.5
Introduction
This functionality allows the system administrator to define extended validation rules regarding data entered or selected in the object edit form.
Validation is performed both on the client side for immediate feedback, as well as on the server side. Server-side validation is always applied, regardless of the input type (manual, import, via API).
Rules can apply to the single field, or field pairs can be defined by specifying master and dependent field, where values allowed in the dependent field are validated based on the selection in the master field.
Administration and usage
Start
Field validation rules can be added at any time in Administrative panel. Open Field Validators section to begin:
A few things to remember before starting:
There is no special validation of the rules, so they must be defined with caution.
Editing an existing object that does not meet new criteria will not be possible.
Setting conditions on fields that are not accessible to specific users that can edit objects, might prevent such individuals from editing an object at all.
A rule defined for parent class like Document will also be applied to child class. In the administration panel, such rule will only be displayed where it was defined (on a parent class)
Define new field validator
Select a class for which you want to add field validators.
Decide if you want to add master/slave field validator or single field validator
For master/slave validation, leave "dependent fields" checked.
For single field validation, uncheck this option
Select field, condition and the desired value
Select add condition
Once this is done, your new validation condition can be seen on Existing conditions list.
Editing Validators
Conditions cannot be edited. To edit a condition, use the Delete button and add a missing condition again.
Overlapping conditions
This is a situation when two or more conditions match a selected field and value.
In such a case, a system will check conditions until a first failing condition is found.
It also applies to master/slave dependency - a first matching rule will be used.
It is advised to avoid overlapping conditions like in this example:
The example above would read:
For field Function having value Personal or Service, Areaklas field must be LOA or BOA
For field Function having value Personal, Areaklas field must be BIA
In this case, when the function field has value Personal, only one of these rules will be applied in any order. As a result, either LOA/BOA
values will be required, or BIA in the second case. While the intention of the system administrator might have been a situation where
for value Personal, LOA, BOA or BIA are allowed, while for Service, only LOA and BOA. This is not the case and the conditions will not be unified into one set automatically.
To achieve described validation, a configuration looking like this is recommended:
Validator examples
Dependent (master/slave) dictionary fields
Dependent fields are created when selecting "Dependent Fields" configuration. Every time a master field has an indicated value, a rule for Dependent field will be enforced.
What's more, a system will filter out values that are not allowed automatically.
A result visible to the user editing a Space object would be as follows:
Date validation
This example shows how to set allowed date limits on a specific field. Here, we have selected a Revision date to be after 1905-02-25 and after 2019-02-25.
These conditions are also checked independently, so only one validation will be made at a time. If the "after" validation will pass, then the "before" validation will be performed (the order might vary).
Text validation
A text validation can be performed using single or master/slave fields like shown below.
In this example, validation will be performed only if the revision date is before a given date. In that case,
a document number field will be required to start with "HIST-" string, for example, "HIST-234525" will be a valid number.
Number validation
A numeric field validation can be used to create conditions like below. In this case, we have set a requirement on a
Space object Area BRA field to be in the range of 0 to 1000.
A result visible to the user while editing this field will be as follows:
Field rules exceptions
There are some actions that may not apply filed rules.
Import
New import option is now added to import dialog called Apply Field Rules.
If it checked, then the filed validators will be applied during import. Objects from package that do not apply to fields rules will not be added and proper message will be added to Object report. If it's un-checked then no filed validation will be done.
In dialog this option is by default checked (validation turned ON). If import is run by API this option's default value is false (so currently run scheduled imports will not be affected)
Custom plugins - smart fields
Administrator can decide whether Field rules should apply or not when Custom fields plugins are run.
In Custom Fileds\Fields availability tab, new column Apply Field Rules will allow to activate and disable filed rules while plugins run.
Update area
Update area functionality will never trigger field rules validation.
This function was designed just to copy area from corresponding spot to object's metadata (area fields), having field validation seems not needed as it would block area update without chance to meet field rules.