What happened?
The property panel draws the required marker from the schema's top-level required array, which is a fixed list. A field that is required only under a condition cannot be expressed there, so the marker never appears for one, and the panel gives the user no sign that the field has become mandatory until the operator is refused.
JSON Schema states such a rule as allOf: [{ if: { properties: { sibling: { const: value } } }, then: { required: [field] } }], and validation already honours it. Only the marker is missing.
The Aggregate operator needs one: its attribute is required for every function except count, where an empty attribute means COUNT(*). Its schema declares this correctly under definitions.AggregationOperation.allOf. The marker is then produced a second time, by name, in the property panel: operator-property-edit-frame.component.ts:1073 matches operatorType === "Aggregate" && key === "attribute" and calls isAggregateAttributeRequired from line 88 of the same file.
So the rule is written twice, in two languages, and the two can drift. Any further operator that wants a conditional required has to add another such branch, and the panel already carries several field-specific ones.
Expected: the panel reads the rule the schema already declares, so an operator states it once, in its descriptor, and no frontend change is needed to add another. The Aggregate branch and its helper then have nothing left to do.
The rules can sit inside definitions, since one may govern a field in an array item, as Aggregate's does. Matching by field name is enough to resolve them, because the condition is evaluated against the field's own parent model, which is the row for an array item and the operator for a top-level field. A schema's attributeTypeRules blocks use a similar-looking allOf whose if names the sibling directly rather than under properties, and require nothing, so they are distinguishable.
How to reproduce?
Drop an Aggregate operator, add an aggregation, and set the function to sum. The attribute is now required, refused if left empty, and carries the marker only because of the branch above. Declare the same condition on any other operator and the marker does not appear.
Version/Branch
1.3.0-incubating-SNAPSHOT (main)
Relevant log output
What happened?
The property panel draws the required marker from the schema's top-level
requiredarray, which is a fixed list. A field that is required only under a condition cannot be expressed there, so the marker never appears for one, and the panel gives the user no sign that the field has become mandatory until the operator is refused.JSON Schema states such a rule as
allOf: [{ if: { properties: { sibling: { const: value } } }, then: { required: [field] } }], and validation already honours it. Only the marker is missing.The Aggregate operator needs one: its
attributeis required for every function exceptcount, where an empty attribute means COUNT(*). Its schema declares this correctly underdefinitions.AggregationOperation.allOf. The marker is then produced a second time, by name, in the property panel:operator-property-edit-frame.component.ts:1073matchesoperatorType === "Aggregate" && key === "attribute"and callsisAggregateAttributeRequiredfrom line 88 of the same file.So the rule is written twice, in two languages, and the two can drift. Any further operator that wants a conditional required has to add another such branch, and the panel already carries several field-specific ones.
Expected: the panel reads the rule the schema already declares, so an operator states it once, in its descriptor, and no frontend change is needed to add another. The Aggregate branch and its helper then have nothing left to do.
The rules can sit inside
definitions, since one may govern a field in an array item, as Aggregate's does. Matching by field name is enough to resolve them, because the condition is evaluated against the field's own parent model, which is the row for an array item and the operator for a top-level field. A schema'sattributeTypeRulesblocks use a similar-lookingallOfwhoseifnames the sibling directly rather than underproperties, and require nothing, so they are distinguishable.How to reproduce?
Drop an
Aggregateoperator, add an aggregation, and set the function tosum. The attribute is now required, refused if left empty, and carries the marker only because of the branch above. Declare the same condition on any other operator and the marker does not appear.Version/Branch
1.3.0-incubating-SNAPSHOT (main)
Relevant log output