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:

Open

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

1. Select a class for which you want to add field validators. 

2. Decide if you want to add master/slave field validator or single field validator

   1. For master/slave validation, leave "dependent fields" checked. 

   2. For single field validation, uncheck this option

3. Select field, condition and the desired value

4. 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:

Open

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.

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

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.