#741 Let Admins Force-Withdraw An Application Without Notifying

[b-at-neu]

Closes #741

Summary

• Adds an admin-only forceWithdrawApplication server action that moves an application straight to withdrawn from any submitted status — including accepted/rejected — without ever sending an email.
• Wires a destructive Force withdraw entry into the status override dialog and the shared status menu (caret dropdown / table row ⋯), admin-only, hidden for draft/withdrawn, behind a ConfirmDialog that states plainly the applicant is not notified and can edit-and-resubmit.
• Updates docs/PERMISSIONS.md and docs/WORKFLOWS.md in the same PR, since this deliberately reopens the withdraw → resubmit round-trip that withdrawApplication blocks for the applicant's own action — the docs now describe that hole as an explicit, admin-only, audited product decision rather than leaving them asserting a guarantee the code no longer makes.

Changes

• prisma/actions/applications.ts — new forceWithdrawApplication: requireAdmin() → zod → $transaction (scoped findFirst → status eligibility → CAS updateMany → applicationStatusEvent.create) → the same two revalidatePath calls updateApplicationStatus makes. No after() dispatch, ever. Also extracts updateApplicationStatus's inline write-race sentence into the new shared APPLICATION_STATUS_CHANGED_MESSAGE constant (byte-identical).
• lib/constants.ts — APPLICATION_STATUS_CHANGED_MESSAGE and APPLICATION_DRAFT_NOT_WITHDRAWABLE_MESSAGE.
• lib/icons.ts — registers forceWithdraw: CircleSlash in ACTION_ICONS.
• components/features/use-force-withdraw-application.ts — new client hook mirroring use-application-status-move.ts's shape (pending state, action call, toasts, confirmDialogProps).
• components/features/application-status-dialog.tsx — isAdmin prop; destructive Force withdraw block below Change status, gated the same way as that block (!isNonReviewableApplicationStatus); disables the Select/Apply while either write is pending.
• components/features/application-status-menu.tsx — canForceWithdraw/onForceWithdraw props; destructive item below a separator, last in the menu.
• components/features/application-status-header-actions.tsx, application-status-actions.tsx — isAdmin prop; each owns its own useForceWithdrawApplication + ConfirmDialog for the menu entry point, and forwards isAdmin to ApplicationStatusDialog. The table row's two early returns (non-reviewable / terminal-decision) are untouched.
• components/features/applications-table.tsx, applications-results.tsx, app/(main)/(auth)/manage/applications/[id]/page.tsx — thread isAdmin={user.isAdmin} down from the server.
• docs/PERMISSIONS.md — new server-action row; lifecycle table gains "admin only: force withdraw" on the unresolved/accepted/rejected rows; amends the terminal-withdrawal bullet to scope the block to the applicant's own withdrawApplication only.
• docs/WORKFLOWS.md — new AD-13 Force-withdraw an application + TOC entry; amends AP-13, AP-14, PM-14, and XC-9.
• tests/db/application-transitions.test.ts — new forceWithdrawApplication suite.

Testing plan

• As an admin, open /manage/applications/[id] for an applied application → caret → Force withdraw → confirm. Toast says force-withdrawn and names no email; status badge reads Withdrawn; See more shows a new history row Applied → Withdrawn · <your name>.
• Repeat from an accepted application via Change decision → dialog → Force withdraw. The confirm text includes the "already been told they were Accepted" sentence.
• Repeat from a rejected application, and from reached_out / interview_scheduled / reviewing.
• /emails and the application's Email history — no new row for any of the above.
• Sign in as the affected applicant: /applications shows Withdrawn with Edit & resubmit, and no email arrived. Resubmit → back in the queue as Applied.
• As a manager on the same position: no Force withdraw in the caret, the row ⋯, or the dialog, at any status.
• As an admin on a draft and on an already-withdrawn application: no Force withdraw anywhere.
• Two tabs: force-withdraw in tab A, then confirm the same action in tab B → error toast, nothing written twice.
• /manage/applications row ⋯ on an applied row → Force withdraw works from the table too; the row's menu then disappears (expected until Show The See More Caret On Every Application Status #742 restores the terminal-decision caret).
• 375px viewport: the dialog block wraps, the confirm dialog is readable, touch targets stay ≥44px.
• Keyboard only: reach the menu item, open the confirm, Escape cancels before submit and is blocked during.

Automated checks

• npm run prettier:check — pass
• npm run eslint:check — pass
• npm run tsc:check — pass
• npm run test (unit + db, against a local Postgres) — 783/783 pass, including the new forceWithdrawApplication suite (per-status matrix, manager/applicant rejection, no EmailLog row, concurrent-call CAS race)

Notes

• This is a deliberate, product-approved hole in the "withdrawal is blocked from a terminal status" guarantee, scoped to admins only: an admin can put a rejected/accepted applicant back into an editable, resubmittable state. The decision survives permanently in the append-only ApplicationStatusEvent history even though it no longer shows in Application.status.
• Per the plan's scope boundary vs Show The See More Caret On Every Application Status #742: application-status-actions.tsx's two early returns (non-reviewable / terminal-decision rows get no table-row ⋯ at all) are untouched here. Until Show The See More Caret On Every Application Status #742 restores that caret, accepted/rejected reach Force withdraw only through the detail page (Change decision → dialog), which still satisfies "available from any submitted status."

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
aplio	Ready	Preview	Sep 25, 2026 2:29pm UTC

[b-at-neu]

Code Review — Cycle 1 · approved

0 open — no findings

[b-at-neu]

Revision — Cycle 1

rebase-only: resolved conflict with #742's caret restructuring · c1090f5
rebase: components/features/application-status-header-actions.tsx (merged — kept dev's extracted confirmDialog var, added the new force-withdraw ConfirmDialog)
rebase: docs/WORKFLOWS.md (merged — kept dev's PM-14 trigger text for the consolidated caret, kept this PR's Force withdraw happy-path addition)

[b-at-neu]

Code Review — Cycle 2 · needs revision

1 open — 1 🟡 Low (see below)

R2-L1 🟡 Low — Vercel preview deployment failed while run-neon-check is green, so branch-quota exhaustion doesn't explain it. This diff has no schema/migration change and run-prettier-check/run-linting-check/run-tsc-check/run-build-check/run-test-check all pass, so nothing in the changed surface plausibly explains the failure either — worth checking the deploy directly before merging rather than assuming it's noise. https://vercel.com/sga-operational-affairs-projects/aplio/BiTyTdimSfE61fSF2cuhtuMVr6Wy

[b-at-neu]

Revision — Cycle 2

fixed R2-L1 (root cause: branch was 5 merges stale vs dev, missing 747's submittedAt-nullable migration that vercel.json's preview buildCommand applies via prisma migrate deploy against the shared-lineage preview DB, which CI's run-build-check never runs against; rebase onto current dev restored migration-folder parity) · cfabf5a

[b-at-neu]

Code Review — Cycle 5 · needs revision

1 open — 1 🟠 Medium (see inline)

[b-at-neu]

Pipeline Escalation

This PR has hit the 5-review cycle cap with the latest cycle still producing a Medium finding, so the pipeline is escalating for human attention rather than dispatching another automated revision.

Cycle 5 finding (R5-M1, Medium): docs/WORKFLOWS.md's AD-13 "Trigger" bullet says direct caret/table-row access to Force withdraw is scoped to "the four unresolved statuses." This is stale relative to the shipped code — application-status-header-actions.tsx and application-status-actions.tsx both thread canForceWithdraw={isAdmin && !isNonReviewableApplicationStatus(currentStatus)} unconditionally, so accepted/rejected also get Force withdraw directly in the caret/table ⋯ menu (matching docs/PERMISSIONS.md's lifecycle table), not only via the Change decision dialog as AD-13 currently claims.

Context on why this cycled so many times: most of the prior cycles (2–4) were rebase-only dispatches responding to dev outpacing this branch, not new findings — the actual code has been stable since cycle 3's approval. This Medium is a one-line documentation wording fix (correcting "four unresolved statuses" scoping in AD-13 to match the already-correct code and the already-correct PERMISSIONS.md table).

Recommendation: this looks safe to fix directly (either by a human editing the one line, or by approving one more revise-agent dispatch outside the automated cap) — it is not a design disagreement, just a stale doc sentence.

[b-at-neu]

Revision — Cycle 5

fixed R5-M1 · 16770bb

[b-at-neu]

Code Review — Cycle 6 · approved

0 open — no findings