My registration — /r/{ulid}?sig=
Who opens it: somebody who registered days or weeks ago, from a link in their confirmation email.
What they came to do: one of three small things — check what they signed up for, fix something that is wrong (a misspelled name, a new phone number), or say that one person can no longer come.
True when they leave: the record matches reality, or they know who to ask. They never end up in a state where a ticket they are carrying no longer works without being told so.
Decisions already made
- The link is signed: a ulid identifies a registration but proves nothing about who holds it.
- Editing updates the people already there and never adds or removes anybody — a dependent may hold an issued ticket whose code cannot change (I4) and which others' admission points at (I3). Adding someone is a conversation with an organizer, and the page says so.
- Attendee type, group and days are not editable here: they decide price, admission and who somebody is counted under, and a day change voids and reissues tickets.
- Cancelling one person voids their live tickets and gives the place back (the meter follows the status). The person whose shared ticket admits the others: the ticket goes to another adult of the right type in the household if there is one; otherwise it is refused, in words (cancel the children first, or ask the organizers).
- "Someone else is coming" hands one person's place to a named new person before the event starts (week 10): same type, days and household, their tickets reissued with new codes, the old codes void. It replaces one person with one person; it still never adds anybody.
- Edits close at
event.settings.self_service_window_closes_offset_minutes— three days before, in the source event event template. After that the page still shows everything and says changes are closed. - Answers validate against the form version they were answered on (I13), so editing cannot validate differently from registering.
Changing days (Phase 6 week 31)
A person whose type chooses its own days (choose one, or choose many), at an event with more than one day, gets Change days on their line while changes are open. One day at a time for choose-one types; ticks for choose-many. Each day shows the places left.
- It is the organizer's day change (
AttendeeService::changeDays), not a second implementation: the old ticket for a dropped day is replaced by one for the new day, and the old code stops working. - A day that has already started cannot be added or dropped here, and someone already admitted is the organizers' to move.
- A move never lands on a waitlist. A full day refuses the change and the person keeps the days they hold. Joining a day's waitlist, and being moved onto it when a place opens, is not built (docs/decisions-pending.md).
- The household does not follow: it is this person's days only.
Open questions
- Cancelling is free today. Should a paid registration offer a refund, or say "contact the organizer"? (Refund rules are deliberately not wired: a refund does not cancel anything yet, and a cancellation does not refund.)
- Should a cancelled person be removable from the page entirely, or stay struck through as a record?
- Add-to-calendar gives one
.icsfor the whole registration. Per person would be more correct and more clutter.