Automated test status

The registration form loads for an event, showing its name and key fields.

A valid submission stores a row and redirects to the confirmation.

After registering, the confirmation page shows a reference number and the attendee's details.

Bad input re-renders the form with messages, keeping what was typed.

A malformed email address is rejected with a clear message.

The partial unique index blocks a second confirmed registration.

Registering with the same email in a different case is still a duplicate.

The email column uses COLLATE NOCASE, so the database treats Orla.Nolan@Example.com and orla.nolan@example.com as the same person.

The uniqueness rule is per event, not site-wide.

Filling the last two workshop places makes a third attempt fail.

Opening the form for a full event redirects instead of showing it.

Opening the registration form for an event that does not exist returns 404.

A cancelled registration must not show a "You're registered!" page.

Registration 19 is seeded as cancelled, so its confirmation URL 404s rather than reassuring someone whose place was cancelled.

The organiser list shows every registration, including a known attendee from each seeded event.

The bare /admin URL should redirect to the organiser list, not 404.

?event=2 narrows the table to the careers evening only.

Sarah Lydon's seeded workshop registration is cancelled.

The stat panel below the title reports the headline figures, all of them describing the seeded dataset as a whole.

Each row lists the event's venue under the event name.

A column header sorts the whole table on the server, and the direction flips between ascending and descending.

A hand-edited (or malicious) sort value is never trusted: an unknown column is ignored and the table falls back to its default newest-first order, with no error and no SQL reaching the database.

Sorting while filtered to one event keeps that filter in the links.

A registration's detail page shows every stored field: reference, name, email, organisation, dietary needs and event.

Opening a registration that does not exist returns a 404.

The edit form arrives pre-filled with the registration's current details.

Editing updates the stored row and reports success.

Validation applies to edits exactly as it does to new registrations.

Changing the email cannot collide with someone else on the event.

Cancelling flips the status and the workshop gains a free place.

Cancelling an already-cancelled registration is reported, not repeated.

After a cancellation the freed workshop place is usable again.

The per-row action on the list reads 'Manage', not 'View'.

A cancelled registration (Sarah Lydon, id 19) shows a reinstate button and not the cancel button.

Un-cancelling flips the status back and the place is taken again.

Reinstate only applies to cancelled rows.

If the freed place was taken meanwhile, the row cannot be reinstated.

If the attendee signed up again after cancelling, the cancelled row cannot also be reinstated — that would duplicate an active registration.

The home page shows every seeded event with its key details.

Capacity maths on the cards: the workshop has 12 - 10 = 2 places.

Event 5 (the bootcamp) is seeded to capacity, so the home page shows the 'Fully booked' badge and the availability API reports no places left.

The event page carries the full description and practical details.

The event page shows how many places are left (2 of 12 for the workshop).

Visiting an event that does not exist shows a friendly 404 page.

The JSON endpoint used by the JavaScript availability widget.

The availability API returns 404 for an event that does not exist.

Every static URL gets a ?v=<hash> marker so a redeploy never serves a returning visitor a stale stylesheet or script. A cached old stylesheet against new HTML was what once made the events view show the cards and the table at the same time.

The version is a content hash: it changes only when the file's bytes change, so an edited asset is re-fetched while unchanged ones stay cached.

The footer offers a 'DB' link to the read-only database viewer at /db (served by nginx in production, alongside the 'Test status' link).

The home page opens with a stat panel: 9 events across 3 venues, 3 of them free to attend, plus the total places still available.

The table view's headers carry the sort keys the JavaScript uses, and each row carries the values those sorts read (client-side sorting).

The seed data creates the three Galway venues, in order.

Each event's venue_id points at an existing venue (the foreign key).

The join lets us check an event never books beyond its venue's size.

Venue name and address both reach the event page through the join.

The venue page shows the venue's name, address, capacity, description and its list of facilities.

The venue page links to Google Maps directions for the venue address.

The venue page lists events held at that venue, and not events held elsewhere.

Requesting a venue that does not exist returns a 404 page.

Venue names on the home page are links to that venue's detail page.

The /tests page shows the headline totals, the run time and the commit.

Test names are humanised and grouped under friendly headings.

A failing test is shown with a red 'Failed' badge on the page.

With no report file, the page still loads and says so, not a 500.

Every page's footer links to the /tests status page.