[P3][icebox] Enforce role-gated / dependent select option values on the server (visibleWhen is UX-only)

[os-zhuang]

Context

Per-option visibleWhen cascading + dependsOn gating for select / multiselect / radio is implemented client-side (ADR-0058, #2284 · multiselect parity #2717 · radio parity #2728). The resolver is resolveCascadingOptions in @object-ui/core, wrapped by the useCascadingOptions hook and the form renderer.

The code is explicit that this is UX only, not a security boundary — see the header comment in packages/core/src/evaluator/optionRules.ts:

Client-side hiding is UX, not a security boundary: when an option is gated for access-control reasons the server must also reject writes of its value.

The gap

A role-gated option (e.g. visibleWhen: "'admin' in current_user.positions") is hidden from non-admins in the UI, but nothing stops a crafted API write from submitting that value directly. For access-control-sensitive option sets the server must reject a write whose value is not in the caller's offered set (evaluating the same per-option predicate + dependsOn against the server-side record + current user).

Why icebox

No role-gated option set is relied on as a security control today; this is a hardening / correctness follow-up. Pick up when a real access-controlled option field ships.

Scope (when actioned)

• Server-side field validation for select / multiselect / radio: on write, reject values whose per-option visibleWhen evaluates FALSE (and/or whose dependsOn parent is unmet) against the server record + current user.
• Reuse the same predicate semantics as the client (optionRules / CEL evalFieldPredicate) so client and server agree on the offered set.
• This lives in framework (write-time field validation), not objectui.

Refs

• ADR-0058 · 表单支持级联/依赖选项:新增 SelectOption.visibleWhen 通用谓词 #2284 · feat(fields): MultiSelectField per-option visibleWhen cascading + dependsOn gating (#2715) #2717 · feat(fields): RadioField visibleWhen cascading + dependsOn gating; single-source the option resolver #2728 · packages/core/src/evaluator/optionRules.ts

[os-zhuang]

Resolved. Investigation found server-side per-option visibleWhen enforcement already existed in framework (packages/objectql/src/validation/rule-validator.ts → evaluateOptionVisibility, wired into insert / single-update / bulk-update; commits 5a0da03d7, a8aa34c36) for select / multiselect / radio. Two gaps remained and are now fixed in framework PR objectstack-ai/objectstack#3350:

• checkboxes was excluded from the enforced set (CHOICE_FIELD_TYPES) — hidden client-side (objectui#2735) but accepted from a crafted write. Now enforced element-wise like multiselect.
• Numeric option values sent as strings slipped the gate (strict === vs the enum validator's String(...)). Matching now coerces both sides.

All four option widgets (select / multiselect / radio / checkboxes) are now gated on the client (objectui #2717 / #2728 / #2735) and enforced on the server. dependsOn stays a client hint; the server keys off each option's visibleWhen (the cascade parent lives inside the child predicate). Fail-open on unbound current_user / unevaluable predicates is preserved by design.

Closing as done.