When a property references an instance of another model (for example, an Order pointing to a Customer), you can apply an InstanceReferenceConstraint to it to limit which instances can be selected. This constraint has a Filter field that can hold a literal value or, more powerfully, a dynamic reference to another property of the same instance being edited.

Vocabulary

Three concepts to be clear about before continuing:

  • Containing model — the model that contains the constrained property. If you put the constraint on Order.customer, the containing model is Order.
  • Target Model — the model of the instances that can be selected. In the example, Customer.
  • Property — the specific property being constrained. In the example, Order.customer.

Static vs dynamic filter

A static filter compares a Target Model property against a literal value:

Show only Customer instances where region == "Catalunya".

A dynamic filter compares a Target Model property against the value of another property in the containing model, resolved at the time the instance is edited:

Show only Customer instances where region == $ref(Order.region).

When you open Order #42 (region = Catalunya), the customer dropdown shows only Catalan customers. When you open Order #43 (region = Aragón), it shows Aragonese ones. The filter is the same; the referenced value changes depending on the instance you are editing.

How to build a dynamic filter

  1. Create or edit the InstanceReferenceConstraint.
  2. Pick the Model (containing) and the Property you want to constrain.
  3. Pick the TargetModel.
  4. Open the Filter field with the edit button. The filter builder opens against the TargetModel.
  5. Pick a property of the TargetModel and an operator (e.g. =).
  6. The "Value for X" dialog opens, letting you choose where the comparison value comes from.

The "Value for X" dialog

Every time you create a filter inside a constraint, the system shows this dialog so you can choose the value's source:

  • Containing-model properties of the same type — listed as clickable entries. Picking one saves a dynamic reference ($ref), which is resolved at edit time.
  • Use a static value — always available; lets you enter a literal.
  • If the containing model has no compatible property, the dialog says so explicitly with a message ("No compatible properties to reference") and only the static option is offered. This is not a bug — there is simply no suitable field to reference.

For a containing-model property to appear as a reference option, it must be of the same type as the TargetModel property you are filtering. For example, when filtering a String on the TargetModel, only the containing model's String properties show up.

Supported types

You can filter and reference properties of these types:

  • String, Integer, Float, Decimal
  • Boolean
  • DateTime, Date
  • ModelReference, InstanceReference, ModelPropertyReference

Collection properties cannot be filtered at all (neither with literal values nor with dynamic references).

Runtime resolution

When a user opens the constrained instance, Yellow walks through the filters and, for each $ref, reads the current value of the referenced property on the instance being edited and substitutes it inside the filter. If the referenced property is empty, that particular filter is skipped — the selection is not blocked, the condition is simply not applied.

That is why a dynamic filter is so useful when you want to keep relationships between instances consistent: you can force the Customer of an Order to belong to the same region as the Order, without having to duplicate the filter for every possible combination of values.