Custom Field Validator in Editing Forms

1 Configuring Custom Validators
2 Registering the Validation Configuration
3 Defining a Custom Validator Function
4 Applying Validation to a Specific Business Need (ADEO Case)
5 Conclusion
6 Additional Resources

Before version 2025.2.0, creating custom validators in editing forms was challenging because it required modifying standard product files, complicating maintenance and upgrades. Starting with version 2025.2.0, the process has been simplified, enabling you to:

Add new custom validators,
Override existing product validators,
Seamlessly inherit updates from product upgrades without losing customizations.

This documentation offers a structured guide to implementing custom field validators in editing forms, ensuring compliance with metadata rules.

Configuring Custom Validators

To implement a custom validator, you must configure it in a specific JSON file within the project's configuration structure and provide a payload (a JSON object that parameterizes the validator's logic). The payload enhances flexibility by allowing you to pass dynamic parameters, such as field names or validation constraints, making the validator reusable across different scenarios.

The entry point for defining validators in editing forms is $.edit, and the configuration is typically stored in a file under:

<configPathRoot>/edit/<structure-name>/fields/names/<field-name>.json

Registering the Validation Configuration

Let’s explore a simple case where we need to ensure that the value fo the field end date of rights (dterightsend) is after the field start date of rights (dterightsstart).

Configuration File

For the dterightsend field, the configuration is defined in:
src/wedia-portal-apps-configs/starter-kit/edit/asset/fields/names/dterightsend.json

Path Breakdown:

src/wedia-portal-apps-configs/starter-kit → Configuration path
edit → Entry point for editing behaviors.
asset → Structure name. If it’s default, the configuration applies to all structures.
fields → Folder where field configurations are stored.
dterightsend → Name of the field to configure.

Inside this file, the validator is registered within the validators object:

{
  "default": { // edition context
    "validators": {
      "endDateBeforeStartDate": {
        "startDateField": "dterightsstart"
      }
    }
  }
}

Configuration Details:

"default": The editing context (e.g., standard editing).

Supported Editing Contexts

default → All editing contexts.
massimport → Upload v1, Creative Workflow.
quickCreate → Quick instance creation from forms.
bulkedit → Bulk edit

"validators": Object where custom validators are defined.
"endDateBeforeStartDate": The name of the custom validator function.
Payload ({"startDateField": "dterightsstart"}): Specifies the start date field to compare against.

Defining a Custom Validator Function

After configuring the validator, you need to define its logic.

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.

The function accepts the payload and returns a validation function that enforces the defined rule.

Validator Function Example:

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

import moment from 'moment';

// Custom validator to ensure end date is after start date
export function endDateBeforeStartDate(payload) {
  return function (value, entity) {
    const startDate = entity[payload.startDateField];
    if (!startDate || !value) {
      return true; // If either date is empty, validation passes
    }
    // End date must be after start date
    return moment(value).isAfter(moment(startDate)); 
  };
}

Explanation

Payload Usage: payload.startDateField retrieves the start date field name (dterightsstart), allowing dynamic access to entity["dterightsstart"].
Logic: Checks if the end date (value) is after the start date using moment.js. Returns true if either field is empty (no validation required) or if the condition is met.

A personalized message error can be displayed alongside the controlled field's input by adding an entry in the PACKAGED_VueAppI18n bundle for the key general.validations.validator.<validatorName>, here general.validations.validator.endDateBeforeStartDate.

Applying Validation to a Specific Business Need (ADEO Case)

Once we understand how to create simple validators, we can extend this approach to more complex use cases, like the one from the ADEO project.

In the ADEO project, we have a business rule to validate the rights period based on the asset's presence metadata:

If the asset has an Identifiable Presence (i.e., metadata is checked), the period between the start date (dterightsstart) and the end date (dterightsend) must not exceed 5 years.
For assets without Identifiable Presence, the maximum allowed period is 10 years.

Configuration Example:

//$.edit.asset.fields.dteendrights.json
{
  "default": {
    "validators": {
      "maxRightsPeriod": {
        "startDateField" : "dterightsstart", // Start date field name
        "presenceField": "presence" // Field indicating identifiable presence.
        "minPeriod": 5, // Period (5 years) for assets with presence.
        "maxPeriod": 10, // Period (10 years) for assets without presence.
        "unit": "years" // Time unit for the period calculation.
      }
    }
  }
}

Validator Function:

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

import moment from 'moment';

// Custom validator for maximum rights period
export function maxRightsPeriod(payload) {
  return function (value, entity) {
    const startDate = entity[payload.startDateField];
    if (!startDate || !value) {
      return true; // If either date is empty, validation passes
    }
    const hasIdentifiablePresence = entity[payload.presenceField]=== true;
    const maxYears = hasIdentifiablePresence ? payload.minPeriod : payload.maxPeriod;
    const yearsDiff = Math.abs(moment(value).diff(moment(startDate), payload.unit, true));
    return yearsDiff <= maxYears;
  };
}

Explanation

Dynamic Threshold: Uses presenceField to determine the maximum allowed period (minPeriod or maxPeriod).
Calculation: Computes the difference between dates in years and checks against the applicable limit.

Illustration of the validation inside the Creative Workflow’s form

Conclusion

By combining configuration and payloads, it is possible to create custom validators that adapt to diverse business rules. The payload’s flexibility, supporting any valid JSON value, enables to define dynamic parameters like field names or thresholds, ensuring robust validation in editing forms.

Additional Resources

For more details on writing custom validators with Vuelidate, see :

https://vuelidate-next.netlify.app/custom_validators.html

Wedia Product Documentation