Most of the safety rule is already in place on the server. It runs in the same transaction as the save:<\/p>\n
form_v2_visit_save()<\/code> (code\/form_v2_visit.inc.php<\/code>), any accepted change calls form_v2_visit_supersede_candidates()<\/code>. The candidate becomes superseded<\/code>, and every tap on it stops counting. The taps are kept as the record. An unchanged answer is not counted as a change, so re-saving the same value withdraws nothing.<\/li>\n- Nothing can be signed against old copies.<\/strong> Every sign, adopt and finish request checks
form_v2_candidate_is_current()<\/code> under the visit lock, and a superseded printing is refused. This is pinned in scripts\/test-form-v2-sign-state.php<\/code> ("a change withdraws").<\/li>\n- The forms are always generated again from the current answers.<\/strong> Signing stamps only the kept review copy, which is proved against its hash. There is no way to sign a copy that does not match the answers.<\/li>\n
- A signed visit takes no more answers<\/strong> (
closed<\/code> \/ signed<\/code> refusal).<\/li>\n<\/ul>\nWhat is missing is all on the person's side:<\/p>\n
\n- No warning before the change.<\/strong> The page says afterwards<\/em>: "An answer changed after the forms were generated, so those copies, and the signatures on them, were withdrawn." By then the signatures are already gone.<\/li>\n
- Later sections are not flagged<\/strong> when the change reveals new questions in them. That is #166, and I'd build it there (see that issue) rather than twice.<\/li>\n
- A signed visit cannot be corrected at all.<\/strong> That needs amendments (FormsV2Plan \u00a78.5), which are not built.<\/li>\n<\/ol>\n
Proposed plan<\/h2>\n
A. Lock the answers once forms are generated, and confirm before unlocking<\/strong> (the modal from the comment above).\nWhile a current printing exists, the questions show read-only, with a Change an answer<\/strong> button. That button opens a modal:<\/p>\n\nThe forms have been generated (and N lines have been signed)<\/em>. Changing an answer withdraws these copies and their signatures. You will generate the forms again, and everyone signs again.\n[Change answers] [Keep the forms]<\/strong><\/p>\n<\/blockquote>\nI'd use a lock rather than catching the first keystroke. The answers autosave as they are typed, so a modal fired by an input<\/code> event would interrupt typing and is easy to dismiss by accident. Unlocking withdraws nothing by itself. Only the first actual saved change does, so a person who unlocks and then changes nothing keeps the forms.<\/p>\nB. Enforce the confirmation on the server, not only in the page.<\/strong>\nWhile a current candidate exists, a save must carry withdraw_candidate = <pk><\/code> naming it. Otherwise it is refused with code printed<\/code> (and the page shows the modal). This stops a stale tab, a retried request or a future client from silently wiping 36 signatures. The lease already allows only one writing window, so this is a second guard, not the only one.<\/p>\nC. After the change, say what to do next.<\/strong> Keep the existing withdrawal notice. Add, once #166 exists, "New questions appeared in: Emergencies<\/em>, Coordination of Care<\/em>" with links. The Generate button stays available, but see question 3.<\/p>\nD. Tests:<\/strong> a save without the acknowledgement is refused while a candidate is current and accepted when there is none. A save with an acknowledgement naming an old candidate is refused as stale.<\/p>\nQuestions<\/h2>\n\n- Does any change withdraw everything?<\/strong> Today it does: one typo in a notes field means a new printing and every line signed again. The plan (\u00a76) chose that for the first release. The alternative is to keep the taps on forms whose generated copy is byte-identical<\/strong> to the one that was signed, so only the forms the change actually reached need signing again. That is safe because a tap is bound to the copy's hash, but the candidate digest currently binds the whole set, so it is a real change. My recommendation: keep "everything again" for the pilot, and revisit if staff complain.<\/strong><\/li>\n
- Is correcting a signed<\/em> visit in scope here, or a separate issue?<\/strong> That is amendments (\u00a78.5): a new revision, the old signed copies kept, new copies signed. I'd make it its own issue, after submission.<\/li>\n
- Should Generate forms be blocked while a section has new questions nobody has opened<\/strong> (#166)? Or should it warn and allow? I lean towards block<\/strong>, because the answers are printed exactly as they stand.<\/li>\n<\/ol>\n"}