Page MenuHomePhabricator

Support required properties in schemas
Open, HighPublic


The outcome of T359193 is to support required in JSON schemas but loosening the validation step to not take it in account for the top level properties of an schema while reading a configuration. But using it regularly on API submissions and writes in general. This is to circumvent the indirection of a configuration not being available at a given time and making the system unrecoverable from that situation.

Open questions:

This approach is similar to the concept of validation warnings (blocking saving, but not reading) and validation errors (blocking everything), which we introduced in GrowthExperiments. Back then, it was done as part of T312576: Structured mentor list should validate the maximum length of a mentor message (see patch for additional context). This makes me wonder: How should we implement the validation warning system in CommunityConfiguration, now that we have fully-blown JSON Schemas? Should we have a generic concept to mark certain validation rules as "soft" (ignorable on reads, but enforced on writes)? If so, is there a reasonable JSONSchema extension we could use/create to record this sort of decisions within the schema itself? How can we make ReflectionSchemaSource read declarations that are CommunityConfiguration-specific? Is that even a good idea?

Event Timeline

Sgs raised the priority of this task from High to Needs Triage.Mar 25 2024, 5:19 PM
Sgs added a project: Growth-Team.
Sgs moved this task from Inbox to Up Next on the Growth-Team board.

Un-assigning since I am not actively working on the task. Probably needs refinement of acceptance criteria.

Sgs removed Sgs as the assignee of this task.Thu, May 16, 2:08 PM

Change #1034451 had a related patch set uploaded (by Sergio Gimeno; author: Sergio Gimeno):

[mediawiki/extensions/CommunityConfiguration@master] [WIP] Editor: support for required in nested objects