Checklist approvals

approvals

Generated by pnpm gen:checklist-status from docs/qa/platform-checklist/areas/*.json. ⛔ Do not edit this page — edits go to the area JSON and this page follows on the next run. This page is Checklist-approvals.

Approvals — quorum, per-group sign-off (会签), inbox

20 active · 0 planned

Active (20)

id	title	priority	status	personas
approvals.per-group-signoff	Per-group sign-off (会签) needs one approval from EACH group	P1	active	approver holding exactly one group (e.g. manager), second approver holding the other group (e.g. finance/auditor)
approvals.quorum-m-of-n	M-of-N quorum approves at the threshold; one rejection vetoes	P1	active	three DISTINCT users each holding one of the approver positions
approvals.inbox-metadata-actions	Inbox actions are metadata-driven and gated by the viewer's relationship	P1	active	an approver who is NOT the submitter and NOT an override actor (no platform-admin or tenant-admin standing), so record.viewer.can_override is false on the request, the dev admin: the submitter of the invoice request (the own-request case) and an OVERRIDE actor (a platform admin — record.viewer.can_override is true on any PENDING request), for the override half of clause 2
approvals.viewer-gating-submitter-side	A submitter who is not an approver sees no approver buttons	P1	active	submitter holding NO approver position on their own pending request
approvals.notification-deep-link	An approval notification deep-links straight onto the request's page	P2	active	any pending approver
approvals.decision-action-matrix	Every approval action executes its REST route and produces the expected state transition plus a timeline entry	P1	active	dev admin (pending approver on the seeded requests; submitter of the invoice request)
approvals.decision-only-via-service	An approval-parked run cannot be resumed through the generic automation route — decisions go through the approvals service only	P1	active	dev admin (holds finance + legal, so the seeded unanimous request is decidable)
approvals.dynamic-approver-routing	A decision's typed outputs route the next stage: expression approvers resolve from the previous decision at node entry	P2	active	dev admin (org-membership owner — the stage-1 approver of the dynamic-approval demo)
approvals.ooo-delegation-reroute	An active out-of-office delegation reroutes an individually-routed approver to the delegate; expiring the window hands the slot back	P2	active	dev admin — the DELEGATOR A: the delegation row is written BY them FOR them (sys_approval_delegation is self-service-only, so the delegator must be whoever is authenticated), a SECOND REAL runtime account — the DELEGATE B (Ada Auditor usr_showcase_auditor_demo, provisioned as a real login per knownGaps), who holds their own bearer token and decides the rerouted request as themselves
approvals.record-page-decisions	Approve/Reject render on the record page from sys_approval_request's declared actions; Reject fires after ONE dialog; a locking approval hides inline edit	P2	active	dev admin (holds the showcase_manager position, so showcase_budget_approval's manager_review routes to them — a pending approver standing on the record page)
approvals.sla-escalation	A node's SLA escalation fires once past its timeout — the declared action runs and an escalate timeline row lands	P2	active	dev admin
approvals.account-app-entry	A non-admin reaches the full Approvals Inbox from the account app's Approvals entry	P0	active	a NON-ADMIN business user who is a pending approver and has no Setup access
approvals.setup-nav-entry	Setup → Approvals leads with Approvals Inbox, above the raw tables	P2	active	platform admin with Setup access
approvals.pending-count-surfaces	The bell badge and Home's action card agree on the pending-approval count and lead to an app the user can open	P2	active	a non-admin pending approver, an admin with >9 combined unread notifications + pending approvals
approvals.email-action-token-door	The anonymous /approvals/act door: a minted one-tap token renders a confirm page and one POST decides as exactly the bound approver — every dead-token shape is a designed refusal page with no state change	P1	active	dev admin (submitter of the seeded invoice request — remind is submitter-only). Since PR #24620 the remind fan-out mints no token, so the admin drives only the live legs: the reminder at-rest read and the server reads beside the anonymous probes, the ANONYMOUS bearer of an action link: a clean HTTP client holding NO session cookie and NO bearer token
approvals.approver-resolution-matrix	Every approver type resolves the slate it declares — department includes all descendants, deprecated role warns and resolves, and a slate with no concrete person takes the declared onEmptyApprovers fork, never a fake approval	P1	active	dev admin (authors the scratch flows; org owner), Ada Auditor / Mei Phone (real logins since #9308 — directory rows the graph legs resolve to)
approvals.status-mirror-field	approvalStatusField mirrors every request transition onto the business record — through the record lock's whitelist, attributed to the acting user	P2	active	dev admin (authors the scratch flow; decides and recalls), a second real login as submitter where the recall/pending attribution needs a non-deciding identity. The submitter is whoever creates the trigger record, so this login needs create on the trigger object (fixtures.requires[0]). On stock showcase_field_zoo neither seeded demo persona (Ada Auditor, Mei Phone) has it
approvals.inbox-keyboard-flow	Inbox keyboard flow: j/k and arrows move focus, Enter opens the request's page, x selects — and a/r quick-decide through the SAME server transition as the buttons, gated by quick-decidability	P2	active	dev admin (pending approver on the seeded demo requests — several quick-decidable rows plus the dynamic-approval stage-1 row as the NOT-quick-decidable contrast)
approvals.request-page-reply-and-reader-visibility	Approval requests on v18: the request record page serves record:approval_decision and a Reply action that lands in its timeline, enable.approvalsVisibleToReaders lets a plain record reader see the record's requests read-only (and only then), the generic /data door serves request rows by approvals visibility, and titles shown to a reader use only what that reader may read	P1	active	seeded admin (admin@objectos.ai / admin123) — the Default Organization owner and platform admin on a fresh boot, org member — created by the admin with POST /api/v1/auth/admin/create-user (stock showcase self-registration is closed: audience posture invite_only answers sign-up 403 SELF_REGISTRATION_CLOSED); joins the Default Organization as member, not platform admin, and lands mustChangePassword:true, i.e. a HELD session until it changes its password (POST /api/v1/auth/change-password)
approvals.act-door-and-admin-rescue-slate	Approvals on v18: the email action door /approvals/act works through the dispatcher exactly as the self-hosted mount (GET renders, POST redeems, a PUT neither door claims an ordinary 404 miss with no Allow header, a dead link a 200 page, a policy-held session not 403'd before the token), and an approval over an unstaffed position opens on the org administrators as ordinary approvers	P1	active	seeded admin (admin@objectos.ai / admin123) — the Default Organization owner and platform admin on a fresh boot, org member — created by the admin with POST /api/v1/auth/admin/create-user (stock showcase self-registration is closed: audience posture invite_only answers sign-up 403 SELF_REGISTRATION_CLOSED); joins the Default Organization as member, not platform admin, and lands mustChangePassword:true, i.e. a HELD session until it changes its password (POST /api/v1/auth/change-password)