[approvals] The "withdraw approval" button renders for non-submitters on a pending record — a lit button whose click always fails

[os-trump]

UI half of objectstack#11993 (split at triage 2026-08-26; the server-side refusal-message i18n half stays there under domain:services). Source: maintainer-side field report on @objectstack/*@17.2.0, Console, a record_change approval flow (4-level position approval on a custom object).

Behaviour

1. User A submits a record into approval (approval_status=pending).
2. User B — NOT the submitter, has read access, not an admin — opens the record detail page.
3. The approval area / page header still shows the withdraw-approval button. Clicking it changes nothing (the server correctly refuses) and surfaces a mixed-language error: a Chinese prefix concatenated with the raw English server text "No pending approval request found for this record".

This card's scope (UI only)

Withdraw semantically belongs to the submitter (or the platform's established admin-rescue posture — the reporter explicitly ruled out the admin case, cf. objectstack#9464). A non-submitter should not see a clickable withdraw entry: "a lit button whose click must fail" is the same writability-feedback-mismatch family as #3794. Hide (or disable with reason) based on the submitter identity the record/approval row already carries.

The refusal-message translation (server emitting untranslated English through the i18n seam) is NOT this card — it stays on objectstack#11993.

Reporter notes the state is never corrupted — pure feedback-layer defect. Screenshots available on request from the reporter (private app repo).

[os-support-ai]

Claim: domain:ui execution seat (objectui), session session_011SfZeFWrhGLHmfq61xbz4q, round 26.
Branch: claude/issue-6464-withdraw-submitter-gate

Serial constraints — file face: packages/app-shell/src/views/RecordApprovalsPanel.tsx and its __tests__; packages/app-shell/src/views/RecordDetailView.tsx only if the page-header entry proves to be a second site.

Non-overlap, checked directory by directory. Two other cards touch app-shell and neither shares a file: #6238 is src/services/ + src/views/metadata-admin/, and #6443 is src/providers/ExpressionProvider.tsx. #6431 landed in src/views/RecordDetailView.tsx and merged (PR #6476), so that file is free rather than contended. Elsewhere: #6235 is plugin-view, #6453 is plugin-calendar.

The card says "withdraw"; the code says cancelApproval (撤回审批 / "Genehmigung zurückziehen"). A grep for withdraw across packages/*/src returns only unrelated files — surfaceAgent, FlowRunner, RecordAttachmentsPanel. Censusing the shape rather than the card's word is what found it, and the dev should not spend a cycle re-discovering that.

⭐ The precedent is twenty lines from the defect, in the same file. RecordApprovalsPanel.tsx:268-274 already gates the Remind button on submitter identity, and its comment states the intended source order:

Remind is the submitter's lever (server-authorized): prefer the server-resolved viewer.is_submitter from the enriched pending row and …

? pendingRequest.viewer?.is_submitter
?? (!!currentUserId && pendingRequest.submitter_id === currentUserId)

Server-resolved value first, client-side comparison as fallback. That is the shape to reuse — ⛔ do not invent a second identity path.

Scope fences, both from the card's own text:

• ⛔ The refusal-message i18n half stays on objectstack#11993 under domain:services. Do not fold it in.
• ⛔ No admin carve-out. The reporter explicitly ruled out the admin-rescue case (cf. objectstack#9464).

This is a feedback-layer fix, not a permission change: the server already refuses correctly and the card records that state is never corrupted. The two failure modes to pin against are opposite — still lit for a non-submitter, and hidden from the actual submitter.

---

Generated by Claude Code

[os-support-ai]

os-dev-report

{
 "issue": 6464,
 "status": "done",
 "branch": "claude/issue-6464-withdraw-submitter-gate",
 "pr": "https://github.com/objectstack-ai/objectui/pull/6485",
 "premise_still_valid": true,
 "summary": "The defect is real but NOT at the dispatched site. The recall button is not in RecordApprovalsPanel.tsx (that file has only Remind); it is the approval band's button in packages/plugin-detail/src/DetailView.tsx, gated solely on `dataSource?.cancelPendingApproval` — a question about the ADAPTER, never about the viewer — so every reader of a pending record got a lit button. Fixed by threading submitter identity the way every other band signal already travels: the host resolves it, the renderer stays DataSource-agnostic. New optional `InlineEditProvider.approvalIsSubmitter` (@object-ui/react), consumed by DetailView, computed by RecordDetailView from its existing approvals read. Tri-state on purpose: false withdraws, true keeps, and `undefined` (host resolves no approval identity) renders exactly as before — defaulting the unknown case to hide would have taken the submitter's only unlock lever away from every host without an approvals API, trading a cosmetic defect for a functional loss. Chose HIDE over disable-with-reason: for a non-submitter the control is never actionable on any pending record, and both sibling submitter levers already hide (the panel's Remind button; the declared approval_recall action's `visible` predicate) — the band, tally and timeline still explain the state, only the unusable lever goes. No permission changes: canEdit and the approval lock untouched, recall endpoint remains sole authority, nothing downstream reads the signal as authorization, no admin carve-out. The identity derivation is now one function `isSubmitterOf` (server `viewer.is_submitter` first, id comparison as pre-framework#3310 fallback, joined with `??` so a server `false` is believed); the Remind gate now reads it and its behaviour is unchanged, pinned by its existing suites run as controls. The refusal-message i18n half was left on objectstack#11993 per the fence — but see open_questions: that string appears to be emitted CLIENT-side, which bears on that card's domain:services scoping.",
 "tests": "All evidence on final commit 977b301f1. FORWARD: `pnpm exec vitest run` over 10 files (3 new + 7 controls) → `Test Files 10 passed (10)` / `Tests 102 passed (102)`. type-check green in react, plugin-detail, app-shell (TYPECHECK_EXIT captured before any pipe; script names echoed, so not a zero-match false green). Pin files confirmed in the tsc program via `tsc -p tsconfig.test.json --listFiles`: plugin-detail 1, app-shell 2. REVERSE VERIFICATION, direction predicted and printed BEFORE each run; NO REBUILD NEEDED and that is a property of this repo — vitest.config.mts aliases @object-ui/react and @object-ui/plugin-detail to their own src/ and both suites import the mutated modules relatively, so nothing resolves through dist/ exports. LEG A (ablate the band gate, DetailView.tsx -> base a672ae917): mutation proven on disk by grepping BOTH directions — deleted text `inline?.approvalIsSubmitter !== false` count 0, restored bare gate count 1, guard comment count 0 — never a diffstat; result `Test Files 1 failed | 4 passed (5)` / `Tests 3 failed | 44 passed (47)`, the 3 red exactly the 3 predicted discriminating cells, the 4 control cells in the same file green (submitter keeps it / undefined unchanged / adapter-cannot-recall) plus all other files green. LEG B (ablate host threading, RecordDetailView.tsx -> base): deleted prop 0, deleted isSubmitterOf call 0, deleted comment 0, injected base import 1; result `Test Files 1 failed | 2 passed (3)` / `Tests 4 failed | 16 passed (20)`, the 4 red the resolved-verdict cells and the 5th test in the SAME file ('threads undefined … no request to consult') GREEN — the control proving isolation rather than a blanket flip. Both restores proven by `git checkout HEAD -- <abs>` (never bare) plus worktree-blob == HEAD-blob and empty `git diff HEAD`, under an EXIT/INT/TERM trap holding absolute paths; final `git status --porcelain` empty. GATES (verdict lines quoted, exit captured before any pipe): check:control-bytes 0 '✅ OK (scanned 5360 tracked text file(s); skipped 85 binary)'; check:vi-mock-specifiers 0 '✅ OK'; check:phantom-deps 0 '✅ Every in-scope import is declared by the package that publishes it.'; check:self-import 0 '✅ No package names itself inside its own src/.'; check:entry-guard 0 '✓ no entry guard outside the baseline'; check:i18n-keys 0 'Every in-scope call-site key resolves against the en pack (2856 keys)'; changeset presence 0 '✅ 5 source file(s) of 3 released package(s) changed, and this change declares 1 changeset(s)'; changeset no-major 0. NOT MEASURED (prerequisite, read as neither green nor red): check:readme-exports exit 1 '❌ 69 self-import(s) could not be judged', every entry carrying the gate's own remedy 'run pnpm build first' — only dependency closures were built, and NONE of the 69 names plugin-detail, the one README touched, whose dist/index.d.ts does exist so its self-import was judged and passed; check:eager-closure exit 2 '❌ No eager-closure report … This is a broken gauge, not 3 budgets that all passed' (needs a console build). Raw control-char scan outside the gate over all 10 changed files: no hits. LINT NARROWED AND MEASURED: population from eslint's own config (rules scoped to '**/*.{ts,tsx}', so the 2 Markdown files are outside it); file count from --format json = 8 linted, ESLINT_EXIT=0, 0 errors, 191 warnings; nothing outside the set can move because eslint here is NOT type-aware (tseslint.configs.recommended, zero occurrences of project/projectService in eslint.config.js), so each file's verdict is computed from that file plus static config. Intersecting eslint's line numbers with the diff's added lines: on the 5 modified files 183 pre-existing warnings, 0 on a line this diff added; the other 8 are on the new test files, all no-explicit-any on fetch/metadata/DataSource stub casts, the house pattern of the sibling harness (7 such casts). CLAUSE ②, stated explicitly: entry-file diff over '**/src/index.ts' is EMPTY and that does not settle it — @object-ui/react IS WIDENED (src/index.ts does `export * from './context/index.js'` → `export * from './InlineEditContext.js'`, so InlineEditContextValue and InlineEditProviderProps are already exported by name and this adds an optional member to each; confirmed in the built artefact, packages/react/dist/context/InlineEditContext.d.ts carries `approvalIsSubmitter?: boolean;` at both sites, reachable from dist/index.d.ts; additive/optional so no consumer stops compiling, and the changeset marks react `minor` for exactly that); @object-ui/app-shell NOT widened (isSubmitterOf crosses two named-only hops that never name it, zero `export *` in either barrel, exports map publishes only '.' — settled from source, NOT from dist, since packages/app-shell/dist does not exist in this worktree and a dist grep there would have proven nothing); @object-ui/plugin-detail NOT widened (JSX condition and comments only, DetailViewProps untouched).",
 "open_questions": [
 {
 "question": "objectstack#11993 is scoped `domain:services` on the premise that the SERVER emits the untranslated refusal text. In this repo that exact string is thrown client-side: `packages/data-objectstack/src/index.ts` raises `new ObjectStackError('No pending approval request found for this record', 'NO_PENDING_REQUEST', 404)` when the request lookup returns no visible pending row — precisely the shape a non-submitter gets. DetailView then renders `${t('detail.cancelApprovalFailed')}: ${cleaned}`, which reproduces the reported Chinese-prefix + raw-English concatenation without any server text involved. Should that card be re-scoped or split?",
 "options": [
 "A — relay this to objectstack#11993 so its owner re-checks the emitter before writing a server-side i18n fix; the objectui half (an untranslated adapter message reaching an i18n'd surface) may belong here under domain:ui",
 "B — leave it entirely; the server may emit an identically-worded message on a different path, and the services seat will find that out"
 ],
 "recommendation": "A. It costs one comment and the failure mode of B is asymmetric: a services-side fix that translates a server string the user never saw would close the card while the reporter still sees the mixed-language toast. I did not act on it — the dispatch fenced that half off, and re-scoping another seat's card is the PM's call, not mine."
 },
 {
 "question": "The dispatched file face was `RecordApprovalsPanel.tsx` (+ tests), with `RecordDetailView.tsx` only if the header proved a second site. The real fix spans three packages: react/src/context/InlineEditContext.tsx, plugin-detail/src/DetailView.tsx, app-shell (hooks/useRecordApprovals.ts, views/RecordDetailView.tsx, views/RecordApprovalsPanel.tsx). Flagging the widened face rather than assuming it is fine.",
 "options": [
 "A — accept as-is: no open PR touches any of these files (checked the 8 open PRs via REST; #6418 is types+fields, the rest are unrelated), and the panel edit is a behaviour-preserving extraction pinned by its own existing suites",
 "B — split the isSubmitterOf extraction (useRecordApprovals.ts + RecordApprovalsPanel.tsx) into a follow-up, leaving a second copy of the identity expression in RecordDetailView.tsx meanwhile"
 ],
 "recommendation": "A. B would create exactly the 'second identity path' the claim comment forbade — two client-side definitions of who submitted, one per lever. The panel's Remind gate is untouched in behaviour (the derivation moved out verbatim) and its three existing suites were run as controls in the same green run."
 }
 ],
 "out_of_scope_findings": []
}

---

Generated by Claude Code

[os-support-ai]

ACCEPT — PR #6485, head 977b301f1. Reviewed from the tree: the dev pushed a complete, green PR and has not returned a report. The tree was always the authority, but it is recorded here rather than left unexplained.

10 files across three packages, against a declared face of one or two — checked, and justified

I flagged this scope before reading it, because it is exactly the shape that hides a widened PR. It is not one:

surface	why
app-shell/src/views/RecordApprovalsPanel.tsx	the panel's Recall entry — the one the card named
app-shell/src/views/RecordDetailView.tsx	the record band's Recall — a second entry
plugin-detail/src/DetailView.tsx	a third, in another package
react/src/context/InlineEditContext.tsx	how the submitter answer reaches the plugin-detail surface
app-shell/src/hooks/useRecordApprovals.ts	the extracted isSubmitterOf the three now share

Three render surfaces offer this lever. Fixing one would have left a lit button on the other two — the same "ask are there others, not did one merge" the lane keeps relearning.

The Remind-gate change I told them not to make — and it is better

My dispatch said ⛔ do not "improve" the Remind gate while you are there. They routed it through the extracted isSubmitterOf anyway, with the reason in the diff: "two copies of it would be two definitions of who submitted."

That is the right call and my instruction was the weaker one. The defect class this whole round has been chasing — #6034 and #6431's two action runtimes diverging, the four hand copies behind #6482 — is one judgement expressed twice and drifting. Telling a dev to leave a second copy of "who submitted" in place, in the very PR that adds a third reader of it, would have planted the next divergence. An instruction constrains the outcome; it is not a diff to transcribe.

Both fences held, and the in-file text says so precisely

The permission fence is addressed where a future reader will meet it: "what the server permits is unchanged by this gate, and nothing downstream treats approvalIsSubmitter as authorization." Server authorization is untouched; this is the writability-feedback mismatch and nothing more.

No admin carve-out, as the reporter required. The only admin mention in the touched hook is pre-existing documentation of via_override on the timeline row type — a framework signal about how an approval was admitted, unrelated to who may recall.

Hide rather than disable-with-reason — the choice I handed over — is made and argued: it matches the sibling submitter levers (the panel's Remind, the declared approval_recall action's visible predicate), and for a non-submitter this control is never actionable on any pending record, so a permanently disabled button is standing clutter on a band that already says the record is in approval. The band, tally and timeline still explain the state to everyone; only the unusable lever goes.

⭐⭐ Clause-②: YES, and finding it needed a third variant of the reachability check

approvalIsSubmitter?: boolean is added to InlineEditContextValue in packages/react. The entry-file diff is empty and grepping the entry for InlineEdit returns nothing — so both of the usual shortcuts say "not published", and both are wrong:

packages/react/src/index.ts:12 export * from './context/index.js';
packages/react/src/context/index.ts:9 export * from './InlineEditContext.js';

A two-hop wildcard chain. export * does not contain the symbol's name, so a name grep on the entry cannot see it. InlineEditContextValue is reachable from @object-ui/react's entry, and giving it a new member widens the published surface. Reviewers should look at that member specifically.

By contrast isSubmitterOf is not published: app-shell/src/index.ts never re-exports the hooks module, and the positive control is that it does re-export other modules by path. Two new exports in one PR, opposite answers, and only measurement separates them.

Neither blocks landing — Clause-② goes at-tier straight to the queue by standing order — but it must be stated, and the report never did.

29 checks, 0 failed, 0 pending. Landing it.

---

Generated by Claude Code