From 4239466351cf3f09e92311960c65d17812990df0 Mon Sep 17 00:00:00 2001 From: Claude Date: Sun, 25 Oct 2026 02:52:12 +0000 Subject: [PATCH] fix(actions): refresh the contract page after a header status transition Submit, Accept for Review, Send for Approval, Start Signing and Activate answered 200 {"success":true} and toasted success, but the record header kept the old stage and the old button until a manual reload. The spec defaults `refreshAfter` to false (materialized at parse) and the record page re-reads the record only when it is true; Terminate and Start Renewal already set it. `transition()` now sets it for all five. Co-Authored-By: Claude Opus 5.5 (1M context) Claude-Session: https://claude.ai/code/session_017nzWFRUo2U7evMkPdVniAn --- src/actions/contract-lifecycle.actions.ts | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/actions/contract-lifecycle.actions.ts b/src/actions/contract-lifecycle.actions.ts index 4c453f9..3756d04 100644 --- a/src/actions/contract-lifecycle.actions.ts +++ b/src/actions/contract-lifecycle.actions.ts @@ -106,6 +106,14 @@ const transition = ( // rendered zero actions on a draft AND on a signing contract. visible: P`record.status == ${from}`, ...(requiredPermissions ? { requiredPermissions: [...requiredPermissions] } : {}), + // The status this button writes is the status the header shows, and the + // status every one of these `visible` predicates reads. The spec defaults + // `refreshAfter` to `false` (materialized at parse), and the record page + // re-reads the record only when it is `true`. Measured on 17.7.0 (issue + // #94): without it each press answered `200 {"success":true}` and toasted + // success while the header kept the old stage and the old button until a + // manual reload; no `GET` of the record followed the action. + refreshAfter: true, }); /** 提交 — the requester hands the draft over. No capability gate. What limits