Attendees — admin

Who opens it: an organizer looking for one person, or a group lead checking their own list.

What they came to do: find somebody, see what they are registered for, what they answered, and whether they got in.

True when they leave: they know that person's state without opening four screens, and they have not changed anything they should not have.

Decisions already made

• The noun is the organization's — Attendee, Volunteer, Delegate, Participant, Student. Nothing on this screen says "attendee" unless the organization does; every label comes from term('attendee') (terminology.md).
• One row per person per event, not per ticket. Somebody registered for two days is one attendee with two tickets, because "who is coming?" is a question about people.
• Read-mostly. The registration is where a submission changes (registrations.md); a day change goes through its own action so capacity, the household and the ticket all move together (day-change.md); check-ins are append-only and are never edited here.
• Scope applies. A member limited to a group sees only that group's subtree, and search never answers with somebody outside it — not even to say they exist.
• What they answered is on the person, not somewhere else. Form answers, consents and their versions are shown with them, because "did their guardian sign?" is a question about a person.
• Deactivating is how somebody stops coming. The row stays, the ticket stops admitting, and the count of who came is still correct afterwards.

Open questions

• There is no bulk edit. Changing one answer for forty people is an import, which is right and slow.
• Nothing on this screen shows the messages this person was sent; that is the messages log, which is per event.