Who can do this
manage_waivers — held by owner and club_admin only. Not the registrar
and not the membership admin, who are the obvious guesses because they are the
people chasing unsigned waivers all season.
The split is deliberate: chasing a signature and rewriting the release everybody already signed are not the same authority. Publishing is a governance act and it is filed alongside policy publishes and club-settings changes in the audit log.
Reading a waiver needs no capability at all. A family has to be able to read the thing before signing it.
Versions, and the flag that matters
A waiver is published as a version. A signature is against a specific version, forever — what somebody signed in March stays exactly as it was in March.
When you publish a new version you decide whether it is a material change:
- Not material — a typo, a clearer sentence. Existing signatures stand.
- Material — the substance changed. Every existing signature in the club is invalidated and every family goes yellow until they re-sign.
Do this before a season, not during one. It is correct behaviour and it is very loud.
What is on the wire today
The parent signing surface is live: a family sees what is outstanding and signs by typing their full legal name.
The staff forms admin is not built yet. Creating and publishing a waiver
version does not have a screen — ask SwimWin support if you need one changed.
The /waivers route today is the parent's outstanding-waiver signer, not a
club-side document manager.
Also still to come
- Registration form add-ons — paid options attached to the sign-up form
- Required documents beyond waivers — the model reserves "document missing" and "document expired" as gate reasons; the upload surface is Phase 2
Related
- Signing waivers — the family's side
- Every gate reason, explained