Determine if we need backend validation for PropertyDefinition Attributes

This is a product question. The below described problem might not be a problem. We should determine what we want.

Relates to

• https://github.com/ProfessionalWiki/NeoWiki/blob/master/docs/adr/012_Backend_Validation.md
• https://github.com/ProfessionalWiki/NeoWiki/blob/master/docs/planning/Validation.md

Problem

PropertyDefinition Attributes (like precision, minimum, maximum for Number properties; minLength, maxLength for Text properties) are validated on the frontend only. The backend stores whatever values are provided without any validation.

For example, a negative precision value will be rejected by the frontend Number property editor (PR #469), but the backend NumberProperty class blindly accepts it. The backend deserializes these attributes from JSON (NumberProperty::fromPropertyArray) and stores them without checking constraints like:

• Precision must be non-negative
• Minimum must be less than maximum
• minLength must be non-negative and less than maxLength

Since schemas are saved via MediaWiki's standard page save API, any client that bypasses the frontend (API calls, bots, imports) can create schemas with invalid attribute values.

Origin

Originally discussed in issue #461 (Jan 2026). Jeroen noted:

"This issue is a specific case of a more general 'problem': we did not implement validation for PropertyDefinition Attributes yet, or even think about how to go about it."

Morne noted:

"the backend would still allow saving a negative number, because we use MediaWiki's standard page save API"

Verified on 2025-02-05 that no attribute validation exists in the backend. NumberProperty (and other property types) have no validation logic for their attributes, and no PropertyDefinitionAttributeValidator or similar class exists.

Read docs/adr/012_Backend_Validation.md and docs/planning/Validation.md, then inspect NumberProperty::fromPropertyArray and the related property classes. Review issue #461 and PR #469 for the existing frontend behavior. Done means reaching and documenting a decision about backend validation scope and constraints, rather than implementing an unspecified change.