A field that drives downstream display or semantics (status, DQ severity) is edited via a change-preview confirmation that reduces the result into the store - never an optimistic instant save.
Accepted. Reconstructed from the codebase on 2026-06-15 — the entity lifecycle-status control is the established implementation; the 0.28.0 DQ-test severity work (odd-platform#1750) is the newest adopter and the reason the pattern is written down.
Some editable fields are not cosmetic — their value drives downstream display or semantics that other people and systems trust:
a data entity's lifecycle status (STABLE / DRAFT / DEPRECATED / DELETED) drives soft-delete, lineage and group relations, and the header status badge;
a DQ-test severity (MINOR / MAJOR / CRITICAL) drives the dataset's aggregate SLA RED / ORANGE / GREEN colour an operator trusts at a glance.
For such a field two properties matter: a change must be deliberate — a single unconfirmed gesture must not silently reclassify a trusted signal — and the rendered value must equal the persisted record, never an optimistic local guess that can diverge if the write fails. The status control already solved this; the severity control had drifted into the opposite shape (an instant fire-and-forget save, an uncontrolled select, no store reduction), which is the defect odd-platform#1750 fixes.
A field whose value drives downstream display or semantics is edited through a confirmation, and the persisted result is reduced into the store. No optimistic instant-save. Concretely:
A selectable control, not an auto-committing input: choosing a new value opens a confirmation dialog (the shared ConfirmationDialog) rather than persisting immediately.
The confirmation previews the change (old → new) and carries any additional change configuration the field needs (for example the status switch-time / propagate options; many fields, such as severity, need none).
The mutation is awaited, with the success / error toast surfaced; on failure nothing is persisted and the displayed value stays the stored value.
The server result is reduced into the store (a slice extraReducers case, or an action such as updateEntityStatus) so the rendered value derives from the persisted record without a refetch.
The displayed value derives from the store (controlled), keyed by the current record, so navigating between records never bleeds one record's value onto another.
Reference implementation: the entity-status control — SelectableEntityStatus + StatusSettingsForm + the updateEntityStatus reducer. Newest adopter: DQ-test severity (SelectableSeverity), shipping in 0.28.0.
A consistent, deliberate, non-divergent way to edit any consequential field; new such fields conform rather than re-deciding the interaction each time.
No new shared primitive — the pattern composes ConfirmationDialog and the existing menu / select controls, all already shipped.
A confirm step per change is the accepted cost; it is right for fields that drive trusted signals and is not intended for trivial cosmetic inputs, which stay plain controls.
This ADR is descriptive — it standardises the existing pattern and directs reuse; it does not mandate retrofitting every editable field at once.
Last updated
