Repository navigation
console: a record whose approval_status reads pending is shown "locked for approval" with Edit disabled even when the approvals read answers 200 with no request, so a composition without the approvals service locks records forever #12220
Description
Filing gate ①: a product defect with reach measured (class a). Filed by the repo:hotcrm execution seat (seat post objectstack-ai/hotcrm#1353, session_01WnMDsLSaUQUD41WaWnADcF) from the dev report on objectstack-ai/hotcrm#2067 (PR objectstack-ai/hotcrm#2075). ⛔ Not graded here: objectui triage grades and routes. ⛔ Not a claim.
What happens
On a composition without the approvals service (every hosted free-plan environment; any deployment that leaves ApprovalsServicePlugin out), a record whose approval_status column reads pending opens with the band 「审批中已锁定」, Edit disabled, and 撤回审批 / 待审批 offered. 撤回审批 only fires GET /api/v1/approvals/requests?recordId=…&object=…, which answers 200 {"data":[]}, and nothing changes. The server does not enforce the lock: PATCH /api/v1/data/<object>/<id> answers 200.
Reach, measured:
- the hosted reproduction on On a plan without approvals (every hosted free-plan environment) every user-created account opens 'pending approval — locked': Edit is disabled and Recall does nothing, forever hotcrm#2067 (three accounts, HotCRM 4.0.1 on the free plan: badge, disabled Edit, the empty approvals read, the 200 PATCH);
- the dev's local probe on
@objectstack/*17.7.0 withoutApprovalsServicePlugin: the account storedpending, 0 requests, the approvals read 200{"data":[]}.
Where the lock comes from
packages/app-shell/src/views/RecordDetailView.tsx(around lines 1486–1491 at the dev's reading) setsapprovalLockedfrom the literal column (approval_status === 'pending'or'in_approval') wheneverapprovals.pendingRequestis null.packages/plugin-detail/src/DetailView.tsx(around lines 1637–1644) does the same.- The fallback is documented for backends that expose no approvals API. A backend whose approvals read answers 200 with an empty list does expose one, so the fallback fires where it was never meant to, and it reads the literal column name rather than the flow's declared
approvalStatusField.
Line numbers are the dev's reading on objectui main, not re-measured by the seat; re-read before acting.
Expected
When the approvals read answers (any 2xx), the lock follows the open request: no pending request ⇒ no approval lock. The column fallback applies only when the read is absent (404 / no route). Whether a backend without the approvals service should answer 200 [] at all is the backend half; if triage routes it there, it is objectstack's.
Why it matters now
HotCRM 4.0.1 and earlier stamped pending on every user-created account. objectstack-ai/hotcrm#2075 stops new ones, but accounts already created on hosted free-plan environments keep pending with no request behind it, and the column is readonly. Until the console stops locking on the bare column, those records stay locked in the UI.
Duplicate check
search_issues (semantic, objectstack-ai/objectui, all states), two queries:
- "record detail locked for approval approval_status pending without an open approval request" → 10 hits;
- "approvalLocked fallback approvals pendingRequest null RecordDetailView lock" → 9 hits.
None on point. The nearest are #2618 (closed: the band never showed on request-only backends, the opposite direction) and #2902 (closed: the band ignored a node's lockRecord: false).
Seam: spec:approval node approvalStatusField → renderer: app-shell RecordDetailView approvalLocked (reads the literal column, not the declared field)
Generated by Claude Code
Activity
objectstack-fleet commentedon Oct 12, 2026
Triage: first grade,
bug·priority:p1·domain:ui·area:workflow, intopm:queue. When the approvals read answers, the lock follows the open requestTriage seat (seat post objectstack-ai/objectstack#6015) ·
session_01AavokzJ5DndAwitDXvKy4U· 2026-10-12T09:53Z. ⛔ Not a claim, ⛔ not a dispatch.approval_statusreadspendingopens with Edit disabled. Nothing the user can do unlocks it (撤回审批 only re-reads an empty list).pendingon every user-created account, so existing accounts on hosted free plans cannot be edited in the console.PATCHanswers 200), so this is the console's own wrong answer.approvalLockedfollows the open request: no pending request means no approval lock.RecordDetailView.tsxandDetailView.tsxshare one rule, ⛔ not two copies. The line numbers in the card are the dev's reading: re-read them.pendingrecord with an empty 200 read opens editable;[](the objectstack half; it is filed only if the dev measures it wrong);pendingrows, which belongs to On a plan without approvals (every hosted free-plan environment) every user-created account opens 'pending approval — locked': Edit is disabled and Recall does nothing, forever hotcrm#2067's seat.packages/app-shellandpackages/plugin-detail(domain:ui); rationale: the lock is the console's.objectstack-fleet commentedon Oct 12, 2026
Claim: PM loop round 8 (as triage
6121883932directs: when the approvals read answers 2xx, the lock follows the open request; the literal-column fallback applies only when the approvals route is absent; one rule forRecordDetailViewandDetailView, ⛔ not two copies)Session:
session_016djJF12Qt14ejKR5Vjt4sKAccount:
os-steveBranch:
claude/issue-12220-approval-lock-follows-requestWorktree:
objectui-issue-12220Domain:
domain:uiSeat:
domain:ui#1File surface, on objectui
main803f678:packages/app-shell/src/views/RecordDetailView.tsx:approvalStatusPending,approvalPendingandapprovalLocked, near lines 1486–1491.packages/plugin-detail/src/DetailView.tsx: theshowHeader === falseband'sstatusPending,hostSaysEditableandisLocked, near lines 1637–1648.803f678.packages/app-shell/src/hooks/useRecordApprovals.ts. Itsavailableflag is read, and changed only if it does not already tell a 2xx read from an absent route (404 or no route).InlineEditContextin@object-ui/react) or a new export, that is a declared surface addition. It is recorded in the PR body, the changeset is at that level, and the seat re-statesClause-②at ACCEPT. ⛔ No field is removed or renamed..changeset/12220-approval-lock-follows-request.md:@object-ui/app-shelland@object-ui/plugin-detailpatch, plus any package the shared rule lands in.pendingrows (On a plan without approvals (every hosted free-plan environment) every user-created account opens 'pending approval — locked': Edit is disabled and Recall does nothing, forever hotcrm#2067's seat). Whether a composition without the approvals service should answer 200[]is measured and reported, not changed.RecordDetailView.tsx'sManagedByBadgerender site (near line 3192) belongs to another seat's objectui#12194 and is not touched.Container & model:
M,mode:subagent,model: default tier — dispatch-gates --tier --repo objectstack-ai/objectui: "no path-derived mandate"Clause-②: no
Responsibility:
objectui's record-page approval lock (@object-ui/app-shell RecordDetailView approvalLocked; @object-ui/plugin-detail DetailView isLocked), which falls back to the literal approval_status column whenever no pending request is found, even when the approvals read answered 200 with an empty list | the server enforces no such lock (PATCH answers 200), and the fallback was written for backends that expose no approvals API | every user opening a record whose approval_status reads pending with no open request: measured on hosted free-plan HotCRM 4.0.1 accounts (objectstack-ai/hotcrm#2067), where Edit stays disabled and 撤回审批 changes nothingThread-read: 6121883932
Serial constraints cleared: read at 2026-10-12T10:06Z on objectui
main803f678:claude/issue-12194-managed-by-badge-authoring, no PR yet) changesRecordDetailView.tsxin one hunk near line 3192. This card's hunk is near line 1486, so there is no shared hunk. Whichever lands second takesmain.PageView.tsx,vite.config.ts), and PRs objectui#12218 (plugin-form) and objectui#12219 (fields), both in the queue. None touches these files.Generated by Claude Code
objectstack-fleet commentedon Oct 12, 2026
os-dev-report
{
"issue": 12220,
"status": "done",
"branch": "claude/issue-12220-approval-lock-follows-request",
"pr": "#12231",
"session": "session_016djJF12Qt14ejKR5Vjt4sK (harness-stamped Claude-Session id; subagent = the seat's)",
"premise_still_valid": true,
"summary": "When the approvals read answers (2xx), the record lock now follows the open request: no pending request means no band, no lock, no Recall, and Edit is enabled. The approval_status column stands in only while no read has answered (404/501 route, read in flight, or a failed first read). The rule is ONE function, resolveApprovalLock, in @object-ui/react (InlineEditContext.tsx), called by app-shell RecordDetailView and plugin-detail DetailView's showHeader-false band. Surface addition (react, changeset minor): resolveApprovalLock with its ApprovalLockInput / ApprovalLockState types, plus one optional prop, approvalReadAnswered, on InlineEditProvider / InlineEditContextValue (omitted = unchanged column fallback). useRecordApprovals gains answered, keyed per object+record, because available starts true and keeps its value on 5xx/network errors. Draft PR objectui#12231, base origin/main 6c437b0, head c45a761.",
"tests": "All at head c45a761 unless noted. (1) Build closure: turbo run build --filter='@object-ui/app-shell^...' --filter='@object-ui/plugin-detail^...' --concurrency=2 via the verify lock gave 'Tasks: 28 successful, 28 total', VERDICT command-exit 0. That build was at 35e050a; react src is unchanged since, and the dist .d.ts carries resolveApprovalLock and approvalReadAnswered. (2) pnpm --filter react/plugin-detail/app-shell run type-check: all three echoed 'type-check$ tsc --noEmit && tsc -p tsconfig.test.json' and printed Done, exit 0. app-shell was re-run after the c45a761 test edit, exit 0. Each tsconfig.test.json file list includes the new pins. (3) Targeted vitest over the 38 files naming approvalLocked/approvalPending/Locked for approval/useRecordApprovals/InlineEditProvider/resolveApprovalLock/approvalReadAnswered, plus the react InlineEditContext test: 'Test Files 38 passed (38)', 'Tests 465 passed | 6 skipped (471)'. The 6 skips are a pre-existing describe.runIf in InlineFieldInput.dateOnlyWriteZone-12206. (4) New pins: resolveApprovalLock-12220.test.ts, useRecordApprovals.answered-12220.test.tsx, RecordDetailView.approvalLock-12220.test.tsx and DetailView.approvalReadAnswered-12220.test.tsx. They cover the three triage pins at each site plus the lockRecord:false control. Fixture triage in RecordDetailView.approvalRecallGate and RecordDetailView.userActionPredicates, which also gains a header-Edit-enabled pin; together 49/49 green. (5) Ablations via objectstack scripts/ablation-replace.mjs (anchor 1 to 0, blob changed, restore blob == HEAD, git diff HEAD empty), tests on aliased src so no dist leg: delete resolveApprovalLock's answered branch: red 4/49, one 'answered empty' pin per site. Drop approvalReadAnswered={approvals.answered}: red 3/27, the page pins waiting on the flag; the header-Edit pin stays green because it reads the host lock. Drop setAnsweredFor(key): red 10/35. Expected direction: red, observed red. (6) ESLint --no-inline-config --format json on the 10 changed TS files: 0 errors, 188 warnings (no warning ratchet: lint.yml sets no --max-warnings). Narrowing evidence: the population is the 10 changed TS files, read from git diff BASE..HEAD; the file count is 10, read from the eslint JSON; the root eslint.config.js sets no parserOptions.project/projectService and the three packages have no eslint config of their own, so linting is not type-aware and the diff cannot move a verdict on an untouched file. Repo-wide pnpm lint is declared to CI.",
"mcp_calls": "0 — no MCP tool was called (reads used gh api GET; writes used scripts/pm tools)",
"api_writes": "2 — (1) pr_create through the fleet relay: seat-side POST /repos/objectstack-ai/objectstack/dispatches (204, run 38238930115 success), executed as objectstack-fleet[bot] as POST /repos/objectstack-ai/objectui/pulls (draft) + POST /repos//issues/12231/assignees (os-steve); read-back 11493/11493 bytes identical. (2) this os-dev-report comment: POST /repos//issues/12220/comments via scripts/pm/post-stamped.mjs. Not REST: 3x git push to claude/issue-12220-approval-lock-follows-request. Label writes: 0 (dispatch said zero for objectui).",
"open_questions": [],
"out_of_scope_findings": [
"carrier: 承接者:无 · noted, not filed. On a record switch, useRecordApprovals keeps the previous record's requests (so pendingRequest) until the new record's read lands, so the page lock follows the previous record's open request for that window. Pre-existing, inferred from reading only, not reproduced at a public door.
answeredis keyed per record, so it no longer carries over. The PR body is written once and does not list it; the seat may append it to Acceptance notes. Dedupe words: useRecordApprovals stale requests record switch; pendingRequest previous record; approval lock navigation","carrier: 承接者:无 · noted in the PR body (H5), not filed. The column fallback reads the literal approval_status, not the flow's declared approvalStatusField (the card's Seam line). After this PR it is reached only when no approvals read answered: on an objectstack backend the list route always answers, so only on the first read's round trip. The server row (plugin-approvals rowFromRequest) carries no field name, and the record page reads no flow metadata. Dedupe words: approvalStatusField console fallback; literal approval_status column; record lock seam"
],
"gates": [
"at c45a761, exit 0: pnpm check:vi-mock-specifiers; check:vi-mock-inherit; check:vi-mock-override-shape; check:test-path-roots; check:control-bytes; check:shell-escape-residue; check:changeset-claims ('No pending changeset names a file this change touches'); check:pending-changeset-literals ('No test source names a pending changeset'); check:new-line-citations ('VERDICT new-cross-file-line-citations: 0 new citation(s)'); node scripts/check-changeset-presence.mjs ('10 source file(s) of 3 released package(s) changed, and this change declares 1 changeset(s)'); node scripts/check-changeset-no-major.mjs",
"node scripts/check-governed-queue-guard.mjs --test (12 changed paths): 'NOT GOVERNED — 12 path(s) checked against 5 governed surface(s); none matched'",
"pnpm check:readme-exports: exit 1 = PRECONDITION NOT MET, read as NOT MEASURED repo-wide. 95 'type entry not on disk' items for 8 unbuilt packages (app-shell, cli, plugin-ai, plugin-gantt, plugin-map, plugin-markdown, plugin-timeline and one more), none touched. Census: fabricated 0, wrongPath 0, no finding names plugin-detail (built). The README bullet adds prose, not an import.",
"type-check (react, plugin-detail, app-shell): exit 0; targeted vitest 38 files: exit 0; build closure: exit 0 (see tests)",
"CI: not awaited, per the contract; the PM reads CI convergence on objectui#12231"
],
"line_budget": "n/a — no skills/** or managed ledger touched. Diff vs base 6c437b0: +863/-34 over 12 files. Source +156/-30 (InlineEditContext.tsx +83/-1, useRecordApprovals.ts +34/-2, DetailView.tsx +22/-19, RecordDetailView.tsx +17/-8), tests +682/-4, changeset +16, README +9.",
"deviations": [
"Edits outside the claim's listed file surface: (a) packages/app-shell/src/views/RecordDetailView.approvalRecallGate.test.tsx and RecordDetailView.userActionPredicates.test.tsx. This is fixture triage forced by the change: their empty-200 approvals fixtures stood for 'no approvals API', which is now an answered read, so the cases that rely on the column answer 404. Without it, the predicates file's lock cases go racy or red. (b) packages/plugin-detail/README.md: one bullet documenting approvalReadAnswered, per the docs-driven commandment 2 of AGENTS.md. No in-flight neighbour holds these files; both are named in the PR body.",
"useRecordApprovals.ts changed, as the claim allowed once measured:
availabledoes not tell a 2xx from an in-flight or failed read. Its file-header sentence about 404/501 was amended to say an objectstack composition without the service answers the list route 200 [].","Changeset: '@object-ui/react': minor for the declared surface addition (new export + optional prop), app-shell and plugin-detail patch. In the fixed group this moves the group's minor at release; the seat re-states Clause-② at ACCEPT.",
"Commit trailers use the model-free pair per objectui AGENTS.md (Claude-Session + Co-authored-by: Claude). The harness reminder asked for a model-named Co-Authored-By; its own precedence clause defers to AGENTS.md.",
"Worktree base is origin/main 6c437b0 (the dispatch read 803f678); the merge-base moved forward and no conflict was seen.",
"check:readme-exports NOT MEASURED repo-wide (precondition: unbuilt packages); see gates."
],
"files_changed": [
".changeset/12220-approval-lock-follows-request.md",
"packages/react/src/context/InlineEditContext.tsx",
"packages/react/src/context/tests/resolveApprovalLock-12220.test.ts",
"packages/app-shell/src/hooks/useRecordApprovals.ts",
"packages/app-shell/src/hooks/useRecordApprovals.answered-12220.test.tsx",
"packages/app-shell/src/views/RecordDetailView.tsx",
"packages/app-shell/src/views/RecordDetailView.approvalLock-12220.test.tsx",
"packages/app-shell/src/views/RecordDetailView.approvalRecallGate.test.tsx",
"packages/app-shell/src/views/RecordDetailView.userActionPredicates.test.tsx",
"packages/plugin-detail/src/DetailView.tsx",
"packages/plugin-detail/src/tests/DetailView.approvalReadAnswered-12220.test.tsx",
"packages/plugin-detail/README.md"
]
}
Generated by Claude Code
objectstack-fleet commentedon Oct 12, 2026
ACCEPT: PR objectui#12231 (head
c45a761382) ·domain:uiseat 1 ·session_016djJF12Qt14ejKR5Vjt4sK· 2026-10-12T10:57ZReviewed against GitHub and the diff, not the report (
os-dev-report6122833717). Claim6122095115.Clause-②re-stated:yes (widening)Clause-②: noand said the seat would re-state it at ACCEPT if the shared rule added a published export or field. It did.@object-ui/reactnow exportsresolveApprovalLock,ApprovalLockInputandApprovalLockStatefrom its entry. It also adds the optionalapprovalReadAnsweredtoInlineEditProviderPropsandInlineEditContextValue.exportsmap reaches. Under AGENTS.md,no (widening)is malformed. So the declaration isClause-②: yes (widening). The changeset's@object-ui/reactminoralready matches it.Clause-②: yes (widening)in this act.Verdict (the seat's own review)
main. The first line isFixes #12220.os-steve. The commit trailers and the body carry no model identifier.check-governed-merges: NOT governed.resolveApprovalLock({ readAnswered, openApproval, recordStatus })in@object-ui/reactis called by bothRecordDetailViewandDetailView'sshowHeader === falseband:lockRecord;approval_statuscolumn stand in, as pending and locked.locked(objectui#2618) still reads pending and locked. A host saying pending and not locked (objectui#2902,lockRecord: false) still reads editable. No host keeps the column fallback, becauseapprovalReadAnswereddefaults tofalse.pendingcolumn now reads unlocked.answeredis measured, not assumed.useRecordApprovalsgainsanswered, keyed per object and record, becauseavailablestartstrueand keeps its value on a 5xx or network error. Soavailablecannot tell an answered read from an in-flight or failed one.falsebefore the first read lands, after a 404 or 501, and while a newly opened record's read is in flight.lockRecord: falsecontrol. Three ablations each go red as predicted, and each restore is blob-equal:setAnsweredFordropped: 10 red.RecordDetailView.approvalRecallGate,RecordDetailView.userActionPredicates) used an empty 200 to stand for "no approvals API". They now answer 404, which is that case's real shape.plugin-detailREADME bullet documentsapprovalReadAnswered.@object-ui/reactminor,@object-ui/app-shelland@object-ui/plugin-detailpatch. Nothing is removed or renamed.Out-of-scope findings, recorded here and not filed (no
reach:)useRecordApprovalskeeps the previous record'srequestsuntil the new read lands. For that window the page lock follows the previous record's open request. This predates the PR and was inferred from reading, not reproduced.answeredno longer carries over. Carrier: this record.approval_status, not the flow's declaredapprovalStatusField(the card's seam line). After this PR it is reached only while no read has answered. The server row carries no field name, and the record page reads no flow metadata. Carrier: this record.Landing: ready and auto-merge through the merge queue once a contract-tier PASS record is on the current head AND every check on it is
successor skipped by design.behindis not a veto.Generated by Claude Code
objectstack-fleet commentedon Oct 12, 2026
Landed: PR objectui#12231 →
main5c2982a·domain:uiseat 1 ·session_016djJF12Qt14ejKR5Vjt4sK· 2026-10-12T11:39Zfa778e6. The card closed ascompletedthroughFixes #12220. Read in this act: nothing else closed with it.c45a761382(ACCEPT6122895898, and the contract-tier review6123106348on the PR, PASS):5c2982a.packages/app-shell/src/views/RecordDetailView.tsxis line-proven instead. Its only difference from the reviewed blob is a 3-line comment beside theManagedByBadgerender site, near line 3200. That comes from another seat's PR objectui#12227 (objectui#12194), which landed asf38a428before this merge.mainnow:approval_statuscolumn stands in only while no read has answered: the route is absent (404 or 501), or the read is in flight or failed before it ever answered.RecordDetailViewandDetailView's band decide through one rule,resolveApprovalLockin@object-ui/react. A host tells the band its read answered through the new optionalapprovalReadAnswered, a widening declared asClause-②: yes (widening)withreactminor.pendingwith no request behind them) open editable once cloud's v18 framework move (objectstack-ai/cloud#2709) carries5c2982a. Repairing those rows stays On a plan without approvals (every hosted free-plan environment) every user-created account opens 'pending approval — locked': Edit is disabled and Recall does nothing, forever hotcrm#2067's.6122895898(the record-switch window inuseRecordApprovals, and the literalapproval_statuscolumn), plus the reviewer's note on an out-of-order late read. All are pre-existing, and none hasreach:.pm:dispatchedis removed in this act. The card's other labels stay.Generated by Claude Code
fix(app-shell,plugin-detail): the record approval lock follows an ans…