Approvals inbox QUEUE rows still render (and sort on) an amount field the object declares `hidden: true`

[yinlianghui]

Filed unassigned from work on #5565 (the drawer summary card trim). Sibling surface, same missing filter — recording it rather than widening that PR.

What was measured

decisionAmountEntry in apps/console/src/pages/system/ApprovalsInboxPage.tsx picks the one decision-relevant numeric field of the request's payload_json snapshot by matching AMOUNT_KEY_RE (amount|total|price|value|cost|sum|budget|salary|fee|revenue|balance plus the CJK spellings) against the key. It is called from four places:

line	surface	trimmed by #5565's fix?
~1845	drawer summary card lead figure	✅ yes
~444	RecordCell — desktop queue row (· {amount.display}, plus title={label: display})	❌ no
~1649	mobile queue card (· {amount.display}, title={amount.label})	❌ no
~1061	the sortKey === 'amount' comparator	❌ no

So after #5565 lands, a field the app author declares hidden: true whose key matches AMOUNT_KEY_RE is trimmed out of the drawer but still renders inline in the queue list, on both the desktop row and the mobile card — and still drives the amount sort order, which leaks the relative magnitude of a hidden field even to a viewer who never sees the figure.

Same invariant as #5565 and #5553: the app author's hidden declaration is bypassed on the approver's path. Same ruling applies (objectstack#10749, verbatim: hidden: true stays UI-only; internal: true is the serialization primitive) — so the fix belongs in the UI, and this is default UI too.

Why it was NOT fixed in #5565

Scope, and a genuinely different cost model — not an oversight:

• Approvals drawer summary card can render a field the object declares hidden: true #5565's subject is the drawer summary card, one open request, one object. Its metadata read is getObjectSchema(selected.object_name), one cached call, one object.
• The queue is N rows spanning K objects, loaded and paged. Trimming it needs a per-object hidden-field map for the whole page, on the useRecordReadability batching pattern rather than the single read Approvals drawer summary card can render a field the object declares hidden: true #5565 added, plus a loading posture for rows whose object has not answered yet.
• The sort comparator is not a visibility change at all — dropping a row's amount moves it to the bottom of the amount sort, so this is an ordering change with its own acceptance criteria, and it must be decided rather than assumed.

Widening #5565 to cover this would have replaced a bounded, mechanical filter with an unrelated cost model and a behaviour change to sorting.

Note on the interim state

Between #5565 landing and this one, the drawer and the queue row disagree about the same field for the same request: the row shows the amount, the drawer does not. That is strictly an improvement over both showing it, but it is a visible inconsistency and worth closing.

Pointers

• apps/console/src/pages/system/ApprovalsInboxPage.tsx — decisionAmountEntry and its four call sites.
• The seam Approvals drawer summary card can render a field the object declares hidden: true #5565 added: apps/console/src/pages/system/hiddenFields.ts (hiddenFieldNames, readHiddenFields, useHiddenFields) — the reader is already batching-ready; only the hook is single-object.
• The batching precedent for K objects across a page: apps/console/src/pages/system/recordReadability.ts (planReadabilityProbe IS the cost model there).
• Related: Approvals drawer summary card can render a field the object declares hidden: true #5565 (drawer summary card, the fix this was split out of), Approvals inbox detail drawer unconditionally renders a "Raw data (JSON)" panel — exposes hidden: true fields, internal ids and audit columns to business approvers #5553 (raw JSON panel gate) — neither is affected by this one either way.

[os-trump]

Triage: pm:queue added (card had type + domain but no pm-state — half-annotated, sweep case ③, flagged by the domain:ui seat's knock). The hidden-field invariant is already ruled (objectstack#10749: hidden: true stays UI-only, fix lands in UI) and the three unfixed call sites are named with the batching precedent. The sort-comparator half is in scope, not a separate decision: sorting on a hidden field leaks relative magnitude, which is the same invariant — the dev states the chosen ordering posture (drop-from-sort vs exclude-per-viewer) in the PR body with its acceptance criteria rather than assuming silently. Premise re-check at claim: verify #5565's state on origin/main first (its fix defines the seam this card extends). Triage seat session session_01TMpU2R7qfDGR8rHKBay9uJ.

---

Generated by Claude Code

[os-support-ai]

Claim — domain:ui @ objectui execution seat

PM session session_011SfZeFWrhGLHmfq61xbz4q (os-support-ai). Branch claude/issue-6020-approvals-queue-hidden-amount. Labels pm:queue → pm:dispatched in the same stroke as the assign. Thanks to the triage seat for the 14:55Z grading.

Pre-dispatch gate — both steps run

Thread read: one triage comment, no maintainer ruling, no Blocked-by:, no prior claim. Shadow check: no sibling card covers the queue-side defect.

⚠️ I nearly withheld this card as stale — and the check that saved it is the one worth reading

objectui#5565 already landed hidden: true filtering on this very page, and decisionAmountEntry — the function this card is about — already contains the filter:

ApprovalsInboxPage.tsx:379    if (hiddenKeys?.has(k)) continue; // author declared `hidden: true` (#5565)

Seeing that, "already fixed" is the obvious reading. It is wrong. The parameter is optional, and the census of its five call sites is the whole card:

site	call	passes hiddenKeys?
:1845	decisionAmountEntry(selected, hiddenPayloadKeys)	✅ the drawer — what #5565 fixed
:444	decisionAmountEntry(r)	⛔ no
:1649	decisionAmountEntry(r)	⛔ no — queue row render
:1061	decisionAmountEntry(a)?.value	⛔ no — the amount sort
:1062	decisionAmountEntry(b)?.value	⛔ no — the amount sort

So the card's two claims — queue rows render it, and the list sorts on it — are both confirmed on origin/main @ 194fae184, and #5565's fix stops precisely at the drawer.

⭐ A filter that is present in the function but unpassed at four of five call sites reads exactly like a fixed defect. The function body is not the measurement; the call sites are.

⛔ The trap: the naive fix does not work

The obvious repair — pass hiddenPayloadKeys at the four sites — fails, and this must be understood before any code is written:

ApprovalsInboxPage.tsx:721    const hiddenPayloadKeys = useHiddenFields(selected?.object_name);

That set is keyed to selected — the drawer's currently-selected row. The queue renders many rows, potentially spanning many objects, and for them no hidden-key set exists at all. Threading the drawer's set into the queue would apply one object's hidden declarations to every row — wrong answers in both directions, and worse than the current miss because it would look fixed.

⛔ So this is not a four-line argument-passing change. It needs a per-object hidden-key lookup for the rows on screen, and the fail-open semantics hiddenFields.ts documents have to be preserved deliberately rather than by accident.

⚠️ Note the severity context the neighbouring docblock records: on this page hidden was reported from a live EHR deployment as a patient-data control. ⛔ That does not make this card a security fix — hidden is ruled UI-only (objectstack#10749; internal: true is the serialization primitive, and FLS redaction happens at serve time) — but it is why "renders and sorts on it anyway" is worth fixing properly rather than quickly.

apps/console — disjoint from the two concurrent claims (#6306 → packages/components, #5901 → packages/data-objectstack).

---

Generated by Claude Code

[os-support-ai]

os-dev-report

{
  "issue": 6020,
  "status": "done",
  "branch": "claude/issue-6020-approvals-queue-hidden-amount",
  "head_sha": "ff0457c53b55829cf64add42cca3d9401ea3e66f",
  "pr": "https://github.com/objectstack-ai/objectui/pull/6364",
  "pr_number": 6364,
  "premise_still_valid": true,
  "files_changed": [
    "apps/console/src/pages/system/ApprovalsInboxPage.tsx",
    "apps/console/src/pages/system/hiddenFields.ts",
    "apps/console/src/pages/system/hiddenFields.test.ts",
    "apps/console/src/pages/system/ApprovalsInboxPage.queueHiddenAmount.test.tsx",
    ".changeset/approvals-queue-hidden-amount-6020.md"
  ],
  "summary": "Census re-derived on origin/main 194fae184 and all five call sites matched the card exactly: decisionAmountEntry already held the filter, but hiddenKeys was optional and only the drawer (:1845) passed it, while the desktop row (:444), the mobile card (:1649) and both halves of the amount comparator (:1061, :1062) called it bare. Replaced useHiddenFields (single object) with useHiddenFieldsByObject, a per-object lookup on the useRecordReadability batching pattern, plus planHiddenFieldReads as the cost model, and made decisionAmountEntry's hiddenKeys parameter REQUIRED so the compiler closes the defect class rather than these four call sites. The drawer now reads the same lookup, so the two surfaces cannot disagree. Fail-open is preserved deliberately and stated in the PR body.",
  "lookup_design": "useHiddenFieldsByObject(objectNames) returns { forObject(name) }, keyed by object, fed the SAME targets as the readability probe (rows plus selected) so a deep-linked drawer is covered. Chosen because the queue is N rows over K objects: threading the drawer's set through the queue would apply one object's declarations to every row, which is worse than the current miss because it looks fixed. planHiddenFieldReads(names) IS the cost model, mirroring planReadabilityProbe: its length is the number of metadata reads a render adds, so K reads per page rather than N, deduped, first-seen order, non-names dropped, each object read at most once per mount. Empty set stays the single answer for nothing-declared / never-asked / not-yet-answered / read-failed, all of which render today's figure.",
  "tests": "All runs foreground through the shared verify lock, exit codes captured before any pipe. GREEN at head ff0457c53: `pnpm exec vitest run apps/console/` from repo root gave `Test Files 79 passed (79)` / `Tests 896 passed (896)` (VERDICT command-exit 0) — the pre-existing drawer test ApprovalsInboxPage.hiddenFieldTrim.test.tsx is untouched and still green, which is also the regression check on re-pointing the drawer at the shared lookup. New file ApprovalsInboxPage.queueHiddenAmount.test.tsx carries 6 tests over a TWO-object fixture (showcase_purchase hides total_amount; showcase_invoice hides service_fee but NOT total_amount) so the naive one-set fix cannot pass it in either direction; 3 unit tests for planHiddenFieldReads added to hiddenFields.test.ts. ABLATIONS: predictions written to disk before running, both matched exactly. No dist sits between edit and run (app's own source, aliased at package source), so no rebuild leg applies; each mutation was proven on disk (git blob hash changed, injected marker counted, removed anchor at zero) and each restore proven by git hash-object returning the HEAD blob a892b5d1 with git diff HEAD empty. Ablation A (both render call sites neutered): predicted RED with 2 failures, actual `Tests 2 failed | 4 passed (6)` — the render test on the hidden figure (0 expected, 2 got), and the sort test's RENDER assertion, with its row-order assertion still passing as predicted because the comparator was untouched. Ablation B (comparator neutered only): predicted RED with 1 failure on row order, actual `Tests 1 failed | 5 passed (6)`, AssertionError expected [PO-4417, INV-8801, INV-8802] to deeply equal [PO-4417, INV-8802, INV-8801]. The two halves fail independently, so neither rides on the other's coverage.",
  "gates": "Gate set derived by reading the job step lists under .github/workflows (ci.yml, lint.yml, changeset-presence.yml, changeset-guard.yml, control-bytes.yml, vi-mock-specifiers.yml) against this diff. All exit 0, each quoted from its own verdict line: vitest apps/console/ `Test Files 79 passed (79)`; type-check `tsc --noEmit && tsc -b tsconfig.node.json --force` clean (and `tsc --noEmit --listFiles` lists all four changed files INCLUDING both test files, so it is a real measurement, not a vacuous pass); eslint . in apps/console 180 files, errors=0 warnings=211 (JSON reporter) — nothing narrowed, that is the whole package and the only package touched; check-changeset-presence `4 source file(s) of 1 released package(s) changed, and this change declares 1 changeset(s)`; check-changeset-no-major `No changeset declares a major bump.`; check-changeset-fixed `All workspace packages are in the changeset fixed group.`; check-control-bytes `OK (scanned 5237 tracked text file(s))`; check-vi-mock-specifiers `OK (686 relative specifier(s) resolved)`; check-lint-coverage `46/46 packages linted`; check-type-check-coverage `45/46 via type-check, 41/41 packages compile their tests`; check-i18n-call-site-keys `Every in-scope call-site key resolves against the en pack`. Typecheck required building the dependency closure first (pnpm --workspace-concurrency=2 --filter '@object-ui/console^...' build, exit 0): apps/console has no paths mapping, so @object-ui/* resolves through each package's dist and judging before the build would have read missing .d.ts. CI job conclusions are the PM's half, per the standing contract — no waiting done here.",
  "false_assumptions": [
    "None in the card or the claim comment. Both were confirmed as written: all five call-site line numbers still matched on origin/main 194fae184, the drawer-scoped hiddenPayloadKeys trap is real (line 721, keyed to selected), and no per-object hidden-key set existed anywhere on the queue path.",
    "One expectation of MINE was wrong, in the ablation instrumentation rather than in the fix: I predicted the injected marker `new Set(string)` would appear twice in ablation A and it counted 5, because the page already carries 3 such lines on HEAD. The decisive evidence was unaffected (the anchor text counted 0 after replacement, the blob hash changed, and each python replacement asserted exactly one hit), and the count is recorded here rather than silently re-run."
  ],
  "open_questions": [
    {
      "question": "Footer form: the dispatch prompt asked for the bare `https://claude.ai/code` footer on the PR body, while the standing dev contract requires the session-URL form there because the bare form is stripped on every subsequent body edit. Flagging rather than silently choosing.",
      "options": [
        "A. Session-URL footer on the PR body (what I shipped), bare form on this comment as the prompt asked",
        "B. Bare form everywhere, accepting that any later edit of the PR body drops the footer"
      ],
      "recommendation": "A, because it satisfies both: the comment path preserves the bare form the prompt specified, and the PR body keeps a footer that survives edits."
    }
  ],
  "stopped_on": [],
  "out_of_scope_findings": []
}

---

Generated by Claude Code