[finding] approvals: `sys_approval_request.payload_json` snapshots the full raw row and serves it to approvers unfiltered — object-level `hidden: true` and FLS declarations cannot reach inside the JSON blob

[os-zhuang]

Split out of #10734 (MEMBER-filed console defect, moved to objectstack-ai/objectui#5553 for its UI half) during triage. This card is the server-side residual: even after the UI stops rendering its "Raw data (JSON)" panel, the data itself still crosses the wire.

Observation

@objectstack/plugin-approvals writes the submitted record's complete raw row into sys_approval_request.payload_json unconditionally at request-creation time (per the #10734 locator). That snapshot includes internal columns (id, created_by, updated_by, owner_id, organization_id, bare lookup ids) and fields the source object's metadata declares hidden: true.

Any approver who can read the approval request receives the whole blob — the field-visibility machinery (object metadata hidden, FLS) governs columns of objects, and cannot see inside a JSON column of sys_approval_request. So the app author's "these fields are not for users" declaration is structurally unenforceable on the approval path, for every app, today (measured on 17.1.0 by the #10734 reporter's deployment).

Why filed as a finding rather than queued

The right treatment has real design weight and at least three shapes with different audit consequences:

1. Trim at write time (snapshot only non-hidden, business-relevant fields) — cheapest, but the approval record then no longer proves what was actually submitted (audit/replay cost);
2. Trim at serve time by requester (full snapshot at rest, metadata-driven redaction when a non-admin reads it) — preserves audit, needs a serve-path seam;
3. Snapshot an explicit projection declared by the approval process shape — contract-first, but touches ApprovalNodeConfigSchema ($strict, currently has no such field), i.e. spec surface.

Grading should also answer the standing triage question "who is the producer?" — the producer is plugin-approvals' request-creation path, so the domain is services; option 3 would pull domain:spec in.

Not queued pending first-touch grading; no user-visible fix should ride the objectui#5553 UI card.

[huangyiirene]

Triage (first-touch grading): finding → needs-user-decision, domain:services, type Bug. 安全/权限边界属人工地板,不代裁;且有 open 下游依赖 —— objectui#5565(审批抽屉渲染 hidden 字段)正 Blocked-by: 本卡等方向。决策分析(中文):

一句话问题:提交审批的记录会把整行原始数据 —— 包括 app 作者声明「对用户隐藏」的字段和内部列 —— 原样发给每个审批人;字段可见性规则管不进审批快照的 JSON 里,每个 app、今天都如此(真实客户 17.1.0 部署实测,#10734)。

选项:

• A 写入时裁剪:快照只存非隐藏业务字段。业务上 = 审批人立刻只见该见的;代价:审批记录不再能证明「当时提交的究竟是什么」—— 有合规/回放诉求的客户会感知审计缺口。
• B 读取时脱敏:全量快照照存,非管理员读取时按对象元数据裁剪。业务上 = 审计完整 + 审批人只见该见的,对全部存量 app 立即生效;代价:平台要新开一个 serve 路径脱敏缝,实现最重。
• C 契约化投影:审批流程声明「快照哪些字段」(动 spec 的 ApprovalNodeConfigSchema)。业务上 = 像把审批单设计成表单 —— 作者显式挑字段;代价:动公开契约,存量流程需要默认投影策略,AI/作者多一处必填心智。

<!-- os-decision-facets -->

• 项目长远合理性:B 与 C 都保住「审批记录即审计证据」的不变量;C 最合 contract-first 北极星但新增契约键;A 用审计换安全,是走回头路的临时补丁。
• 实际业务拉动:真实客户报障实测在案,非投机面;隐藏字段直达审批人是今天就发生的泄露。
• 防 AI 犯错:B 是平台结构性兜底 —— AI 写的 app 忘了什么都不会泄(静默泄露变结构性不可能);C 靠作者每流程写对投影,写漏时仍需 B 类兜底。
• 创业阶段不扩散:A 最便宜但制造审计债;B 一次投入平台级生效;C 扩契约面,宜等真实投影需求再加。
• 推荐:B(serve 时按请求者脱敏),回退 A;C 留作后续真实需求出现时的叠加项。
• 本分析看不见什么:payload_json 的现有消费者(回放、报表、审计导出)是否依赖会被裁掉的字段未清点;serve 路径有几扇门(REST/ObjectQL/导出)未逐一数过 —— B 的实现面大小取决于它。

回一个字母即可(A/B/C;「B,但先清点消费者」也可)。裁后执行:裁定后本席出箱入队 services 席派发(B ⇒ 附 serve 门清点为第一步;若涉 spec 投影则拆 spec 半边转该席),objectui#5565 依裁定方向解锁。

---

Generated by Claude Code

[huangyiirene]

Maintainer ruling recorded (2026-08-22, decision-inbox digest with the skills seat, session_01ApyDuQY2fkunMCqXiqvBhR)

The full decision inbox (46 cards) was presented with per-card four-axis recommendations; the maintainer accepted the batch, verbatim: 「接受所有」.

Ruled: Option B — read-time masking, with the consumer inventory first. The full snapshot stays at rest in sys_approval_request.payload_json (preserving the approval record as audit evidence of what was actually submitted), and metadata-driven redaction is applied at serve time when a non-admin reads it, so hidden: true/FLS declarations become structurally enforceable on the approval path for all existing apps at once. Per triage's post-ruling plan, the first step of the dispatched work is the inventory triage flagged as unmeasured: enumerate payload_json's existing consumers (replay, reporting, audit export) and count the serve doors (REST/ObjectQL/export) the redaction seam must cover. Option A (write-time trimming) remains the fallback; C (a contract-declared projection) is deferred until a real projection need appears. objectui#5565 unblocks in this direction.

State: needs-user-decision removed → pm:queue (ready for dispatch).

---

Generated by Claude Code