Custom Field Validator in Editing Forms

Since version 2025.2.0, it is now possible to create a custom validator for a field in an editing form, such as:

• Creative Workflow

• Edition of an asset

• Bulk edit

Previously, projects could only reference built-in Vuelidate validators and a few custom validators provided by the product in configuration. Now, it is possible to write project-specific validation functions that dynamically validate a field's value based on the state of other fields. This provides greater flexibility and allows for more complex validation logic directly within the editing forms.

Implementing a Validation Rule (ADEO Case)

To illustrate how to define a custom validator, let's take a concrete example from the ADEO project.

In this project, we need to enforce the following validation rule:

If an asset has an Identifiable Presence (metadata presence checked), the period between the start date (dterightsstart) and the end date of rights (dterightsend) must not exceed 5 years.

For all other assets (without "Identifiable Presence"), the maximum allowed period is 10 years.

1. Registering the Validation Configuration

The entry point for defining validators for a field in editing forms is: $.edit.

In this example, we configure the field that stores the end date of rights (dterightsend) and declare the validator in:

src/wedia-portal-apps-configs/starter-kit/edit/asset/fields/names/dterightsend.json

Path Breakdown

• edit → Configuration entry point for defining behaviors in editing forms.

• asset → Structure name. If named "default," the configuration applies to all structures.

• fields → Folder storing the asset's field configurations.

• dterightsend → Name of the field to configure.

Inside the validators object, we define the custom validators:

• Key → Name of the custom validator function.

• Value → Payload passed as an argument to the custom validator function.

Supported Editing Contexts

• default → All editing contexts.

• massimport → Upload v1, Creative Workflow.

• quickCreate → Quick instance creation from forms.

• bulkedit → Bulk edit.

Configuration Example

{
  "default": {
    "validators": {
      "maxRightsPeriod": {
        "minPeriod": 5,
        "maxPeriod": 10,
        "unit": "years"
      }
    }
  }
}

2. Defining a Custom Validator Function

To register a custom validator function, personalize the following file :

src/common/components/common/CwInputs/validation/projectCustomValidators.js

This file is delivered empty and should be overridden inside the root folder __perso.

Writing the Validation Rule Function

Custom validators get the configured payload as an argument and should return a validation function, which receives the following parameters:

1. value → The current field value to validate.

2. entity → The full entity being edited (providing access to other field values).

Example Custom Validator:

import moment from 'moment';

// eslint-disable-next-line import/prefer-default-export
export function maxRightsPeriod(payload) {
  return function (value, entity) {
    const startDate = entity.dterightsstart;
    if (!startDate || !value) {
      return true; // If either date is empty, validation passes
    }
    const hasIdentifiablePresence = entity.presence === true;
    const maxYears = hasIdentifiablePresence ? payload.minPeriod : payload.maxPeriod;
    const yearsDiff = Math.abs(moment(value).diff(moment(startDate), payload.unit, true));
    return yearsDiff <= maxYears;
  };
}

This validator ensures that the period between dterightsstart and dterightsend complies with the defined constraints based on asset structure.

A personalized message error can be displayed by adding an entry in the PACKAGED_VueAppI18n bundle for the key general.validations.validator.$validatorName, here general.validations.validator.maxRightsPeriod.