Since 3.5

Introduction

This functionality enables the system administrator to establish extended validation rules for the data entered or selected in the object edit form.

Validation is carried out on both the client side to provide immediate feedback, and on the server side. Server-side validation is consistently applied, irrespective of the input type (manual entry, import, or via API).

Rules can be applied to a single field; alternatively, field pairs can be defined by specifying a master and dependent field. In this case, values allowed in the dependent field are validated based on the selection made in the master field.

Administration and Usage

Getting Started

Field validation rules can be added at any time in Administrative panel. To begin, open Field Validators section:

Open

A few important considerations before getting started:

• Rules must be defined carefully since there is no special validation process.

• It will not be possible to edit an existing object that does not meet the new criteria.

• Setting conditions on inaccessible fields for specific users who can edit objects may prevent them from editing at all.

• A rule set for a parent class, such as Document, will also apply to its child classes. In the administration panel, this rule will only be displayed where it was originally defined (on the parent class).

   

Define New Field Validator

1. Choose the class for which you intend to incorporate field validators.

2. Determine whether you need to add a master/slave field validator or a single field validator:

   1. When implementing master/slave validation, ensure that "dependent fields" is selected.

   2. For single field validation, deselect this option.

3. Pick the field, specify the condition, and set the desired value.

4. Click on "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

Overlapping conditions occur when two or more conditions match a selected field and value.

In such instances, the system will check conditions until it encounters the first failing condition. This principle also applies to master/slave dependency - the first matching rule will be utilized.

It is advisable to avoid overlapping conditions, as illustrated in this example:

Open

• When the Function field has a value of Personal or Service, the Areaklas field must be LOA or BOA.

• If the Function field has a value of Personal, then the Areaklas field must be BIA.

In this scenario, when the function field is set to Personal, only one of these rules will apply in any order. Consequently, either LOA/BOA values will be required or BIA in the second case. The intended system administration might have aimed for a situation where LOA, BOA, or BIA are allowed for value Personal and only LOA and BOA are allowed for Service. However, this is not presently achievable as the conditions will not automatically merge into one unified set.

To achieve the described validation, it is recommended to use a configuration that looks like this:

Validator examples

Dependent (master/slave) dictionary fields

Dependent fields are created when "Dependent Fields" configuration is selected. Whenever a master field has a specified value, a rule for the dependent field will be applied.

Additionally, the system will automatically filter out disallowed values.

A user editing a Space object would see the following result:

Date Validation

This example demonstrates how to establish permitted date boundaries for a particular field. In this case, we have specified that the Revision date must be after 1905-02-25 and also after 2019-02-25.

These conditions are evaluated separately, ensuring that only one validation is executed at a time. If the "after" validation succeeds, then the "before" validation will be conducted (the order may vary).

Text validation

Text validation can be carried out using single or master/slave fields, as shown below.

In this example, validation will only occur if the revision date is before a specified date. In such cases, a document number field must begin with the "HIST-" string. For instance, "HIST-234525" would be considered a valid number.

Number Validation

Numeric field validation can be utilized to establish specific conditions.

In this instance, a requirement has been defined for the Space object Area BRA field to fall within the range of 0 to 1000.

A result that the user will see while editing this field is 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 the checked option is selected, the field validators will be applied during import. Objects from a package that do not adhere to the field rules will not be added, and a proper message will be included in the Object report. If it's un-checked, then no field validation will be performed.

Custom Plugins - Smart Fields

Administrators now have the capability to control the application of field rules when executing custom field plugins.

In the Custom Fields\Fields Availability tab, a new column labeled Apply Field Rules allows for the activation and deactivation of field rules during plugin execution.

Update area

This function was specifically designed to copy the area from the corresponding spot to the object's metadata (area fields). It seems that having field validation is unnecessary as it would prevent area updates without providing an opportunity to adhere to field rules.