Events — admin

Who opens it: an organizer setting an event up, or coming back to change a detail a fortnight later.

What they came to do: see every event this organization is running, and open one to change its dates, its days, who may come, how they sign up, and when it goes live.

True when they leave: the event says what it is going to do, and every change has a name against it in the audit log.

Decisions already made

• Status moves one way, through the service. draft → published → live → closed → archived, and only EventService. Nothing sets a status by editing a column: publishing has to check the plan, open the registration forms and schedule what was scheduled, and a column edit would skip all of it.
• Draft is invisible. A draft event has no public page and no open form — its link 404s. Publishing is the moment anything becomes real, which is why the button says so.
• Days are the unit everything else hangs off. A ticket admits somebody to a day, a check-in point accepts named days, capacity is per day. An event with one day still has one — the organizer sees "Day 1" and the machinery sees a row.
• Times are stored UTC and shown in the event's own timezone, including in exports. A day that starts at 8 AM in Chicago starts at 8 AM on the screen of somebody reading it in London.
• Its parts live in the tabs below, each with its own page here: days and capacity, check-in points, registration forms, emails and reminders, rules, scanning devices.
• Start from an event template rather than an empty form when the shape is a shape somebody has done before: event-template-import.md and event-templates.md.
• Archiving is not deleting. An archived event keeps its registrations, tickets and check-ins, because a question about last year has to have an answer. Data goes when retention says so, not when a screen says so.

Open questions

• Nothing on this screen says what an event is costing against the plan's attendee cap; that lives on usage.md, one click away, and the first week of a big event is exactly when somebody wants both at once.
• Duplicating last year's event is "export it as an event template, then import it", which works and is not obvious.

What a delegate sees when they choose

A day picker on a registration form shows the agenda as a schedule: grouped by date, in time order, each with its time, its track, and how many places are left — "3 places left". A full one that keeps a waitlist says full, waitlist only and can still be chosen; one with no waitlist says closed and cannot, and neither can one that has already started.

Where somebody may choose more than one, ticking a day marks everything that runs at the same time as a clash straight away, so nobody fills in a whole form to be told at the end. Saving is checked again on the way in, so the rule holds whatever the browser does.

The agenda grid

Agenda, on an event's screen, shows the days as a grid: one table per date, a row per time slot and a column per track, so a week-long conference reads at a glance instead of as hundreds of rows. Each cell names its day, how many places are held against its capacity, and its price.

Build a grid makes the whole agenda at once. Give it the first date and how many dates, the time slots that repeat on each one (typed start and end either side of a dash — 9:00-10:00), and the track names, plus a capacity, price and waitlist setting to apply to every one. Leave Only check it ticked the first time to see what would be made. The codes it gives are D1-S2-T3 — date 1, slot 2, track 3, with an optional prefix of your own — so you can change a time in the builder and run it again: it updates what it made rather than making a second set. At most 1,000 at a time.

The days list copes with that many: search by code, name or track, filter by track or by date, and choose how many to show a page.

Two days at the same time

Nobody can be given two days that cover the same time — not on the registration form, not at the desk, and not when an organizer changes somebody's days. Days that run back to back (one ending at 10:00, the next starting at 10:00) are fine. Where an event means its days to overlap — a whole-event day sold beside the ones it covers — turn on Allow overlapping days on the event's edit screen, under Days that overlap.

The check judges only what is being added, so a person who already holds two overlapping days (from before the event turned the allowance off) can still have an unrelated day added or removed.

Days from a spreadsheet

On an event's Days list, Import from a spreadsheet creates many days at once; Blank spreadsheet downloads the columns to fill in (code, name, date, start, end, track, capacity, waitlist, price). Save your sheet as CSV, choose the file, and leave Only check it ticked the first time: it lists what would be added or changed and every row that cannot be used, with its line number and the reason, and saves nothing. Untick it and run again to import. Rows are matched by code, so importing the same sheet twice changes nothing, and an edited sheet updates only the days that differ. Times are the event's local time. A file may hold up to 1,000 days.

A day's price and its rules

A day can have a price (blank is free of charge) — what it costs to add on its own. A priced day also has Refunds and holds: how much a release gives back (by default everything until 21 days before it starts, half until 7 days before, then nothing), when changes close, when someone from the waitlist pays, and how long an offered place is held (never longer than the time left until the day). Leave a box blank to follow the event's default, which is set under Refunds and holds for priced days on the event; the grey figures show what applies.

When someone is moved onto a priced day, its price is added to what they owe. When they are moved off it, the day comes off the bill and they get back what the rules allow at that moment; what is not given back stays paid, and the change's record shows the amounts. After a day's changes close, only an organizer can still change it, by ticking Change anyway.

When a place opens on a priced day, the next person on its waitlist is told it is theirs and the seat is held while they pay: the day's price is added to what they owe, and the hold lasts the hold window or the time left before the day, whichever is shorter. Once they pay, the place is theirs. If the time runs out first, the seat goes to the next person in line. A day can instead be set to let the waitlist person pay at the door, or not at all.