proposal: a value required only under a condition

[delchev]

Proposal 0036. required: true says a value must always be there; most business rules about a missing value are not like that - the value is needed for ONE way of handling the record and meaningless for the others. An invoice sent by e-mail needs the customer's e-mail address, one sent by post does not, and one handed over needs neither, so required on the address would refuse every customer who is never e-mailed. checks: has exactlyOne, itemsSumEqual and itemsMin, none of which say it either - so nothing says it, and an e-mailed invoice whose customer carries no address reaches "sent" with nobody to send it to.

The proposed requiredWhen names the value (a field, or a one-hop Relation.field), the condition it is required under, and optionally the status at which the condition is evaluated - the last being what makes the rule expressible at all, since a record still being typed has not chosen how it will be sent.

Also covered: why an uninterpretable condition has to be a validation error in both directions, why the condition's operands are restricted to the types an equality is exact on, and the two hand-written workarounds the shape replaces (a step before the sending action - about fifteen declarative lines plus a class for one sentence of rule, landing the user on a hold task instead of a refusal - and a step after it, whose refusal has nowhere to go).

Implemented in Eclipse Dirigible: eclipse-dirigible/dirigible#7129 (issue eclipse-dirigible/dirigible#7094).

🤖 Generated with Claude Code