Form conditions

A screen column can react to the value of another field of the same row: appear only for one kind of record, become required, lock itself, take a forced value, change its list of values, or not be written at all. The screen itself can make whole rows read-only. All these settings use the same condition shape.

For a step-by-step use in the screen editor, see Screens → Conditional fields.

---

At a glance

---

The condition

A condition names a field of the same row and the value it must have — or a list of values, any of which matches:

{ field = "STATUS", value = "CANCELLED" }
{ field = "PAYMENT_METHOD", value = ["TRANSFER", "DIRECT_DEBIT"] }

A setting holds a list of conditions: all of them must match (AND). Values are compared as text, without their leading and trailing spaces, so a code padded with spaces still matches. Field names are matched regardless of case.

In the screen editor, each setting is a list on the column's inspector: one line per condition, with the field picked from the screen's columns.

---

Settings on a column

Setting	Inspector tab	Effect
visible_when	Filter	Dialog: the field shows only while the conditions match the form's values. Grid: the column hides when a filter of the screen is set to a value outside the condition; with that filter empty, the column stays.
required / required_when	Edit	The field is marked required (asterisk), always or only while the conditions match.
disabled / disabled_when	Edit	The field is read-only, always or only while the conditions match.
disable_on_add	Edit	Read-only when a row is added, editable afterwards — for a value assigned on creation.
disable_on_edit	Edit	Read-only once the row exists — for a key that must not change. Applies to the dialog and to grid editing.
default	Defaults	The value proposed when a row is added.
default_when	Defaults	While its condition matches, the column takes the given default and is locked. With lock off, the value is only proposed and stays editable. With several rules, the first that matches wins. Re-applied when the deciding field changes, in the dialog and the grid.
rules_when	Rules	While its condition matches, the column uses another rule — another lookup, enum or Boolean, with its own lookup parameters and returned values — or none (plain input). The first match wins; otherwise the column's own rule applies.
write_when	Defaults	The column is written only while the conditions match. Otherwise the server writes a neutral value (blank or 0) and the dictionary default or rule is not applied — for a field that means nothing for this kind of row.

A static setting and its conditional version combine simply: when the _when list is empty, the static flag decides; when it is filled, the conditions decide.

---

Setting on the screen — editable_when

Set in the General tab of the screen editor, editable_when says when an existing row may be changed or deleted:

editable_when = [{ field = "PERIOD_STATUS", value = ["OPEN", "VALIDATED"] }]

A row that does not match is read-only: plain cells in the grid, a view-only dialog without Save or Delete. The server refuses a change to such a row as well. Adding rows is not affected.

---

What happens on save

• Hidden fields — on an update, a field hidden by visible_when is not sent: the column keeps its stored value. On an insert, a hidden field is sent only when it holds a value.
• Locked fields — their value is sent as it is.
• Where it is checked — visible_when, required_when, disabled_when, default_when and rules_when act in the browser, as the user types. editable_when and write_when are applied by the server too, whatever the client sends.

---

Action prompts

The fields of an action's prompt dialog accept visible_when, required_when and disabled_when with the same shape, evaluated against the prompt's own fields. See Actions and lifecycle.

---

What's next

• Screens → Conditional fields — set them up in the screen editor, with examples.
• Screens → Columns — every other column setting.
• Dictionary — the rules a column inherits.