Digest frequency
notifications.digest.frequency
Set here · org Acme Corp
The hard part of this UI is not the inputs — it is communicating why a setting has
its value and why some settings cannot be changed. Each block below is a distinct
EffectiveConfigEntry shape the editor must render differently. Getting these wrong
produces a form that lies.
An override exists at the scope being edited. This is the only case where
"Reset" is meaningful, and it is where the unset-vs-pin distinction bites.
These produce the same value today and diverge tomorrow. Collapsing them into a single "Reset to inherited" control is the most likely design error in this flow, and it is silent: nothing looks wrong until the parent changes and the child does or does not follow.
Editable here — writing creates an override at this scope. The badge names the ancestor; "Inherited" alone does not tell an admin who to talk to.
The lock owner comes from lockedBy, and the explanation from
lockReason. A generic "you cannot edit this" is a design failure: the contract carries
exactly who locked it and why, so the UI must say so rather than send the admin hunting.
🔒
portal Acme Portal locked this value.
lockReason: "SMS is disabled tenant-wide pending carrier review."
You are editing org Acme Corp, beneath the lock — the server refuses
writes here with LOCKED_BY_ANCESTOR.
Distinct from a lock: nobody can change it anywhere, so there is no ancestor to name and no "ask your admin" path. Showing this as a lock would misdirect.
isReadonly: true
The key exists and resolves, but may not be set here. No input is offered —
an enabled control that only fails on save (SCOPE_NOT_ALLOWED) is the failure mode this
state exists to prevent.
Every key resolves to something even with no overrides, because
defaultValue is always present. This must not read as "unset/empty" — the value is real
and in force.
Contract. Every block is one EffectiveConfigEntry:
source (a typed Scope — scopeType + scopeId, never a
bare id), locked, lockedBy, lockReason, editable,
plus definition.isReadonly / definition.allowedScopes. The four
reasons a control is disabled — locked, readonly, scope-not-allowed,
no Permit grant — are visually distinct, because the user's next action differs in each.