Public Participant List

The original was specific to one event and assumed a single custom list (School) in event.custom_list_1_id:

The screen keeps the selection semantics of this query exactly (see Participant Selection Rules) but drops the personal columns and generalises the single School join to all three custom-list slots.

The screen and its backing endpoint are reachable with no credentials at all.

The portal’s other screens sit behind authGuard, which bounces anonymous visitors through /login into a guest session — auto-creating a wp_users row and issuing a JWT. That mechanism is deliberately not used here. This link is intended to be published widely (event website, WhatsApp groups, entry confirmation emails), and creating a user account for every person who opens it would pollute the user table with records that represent nobody.

The route is therefore declared in the public block of app-routing.module.ts, alongside /login and the error routes, rather than in the authGuard-protected EntityRoutingModule.

The withheld columns are not filtered out at the DTO layer — they are never read. The backing query is a JPQL constructor projection naming only the exposed columns, so the generated SQL does not touch date_of_birth, gender or identity_number at all. The privacy guarantee is a property of the query, not of developer discipline, and is asserted directly in PublicEventParticipantResourceIT.

Payment status is omitted deliberately. Entries appear whether or not payment has cleared, so the screen carries a standing note to that effect — without it, an unpaid entrant reads their own absence from a "paid" column as a lost entry.

The endpoint applies no organisation filter. It resolves the event by id, and the event’s organiser is whatever the schema says it is; nothing in the request asserts an organisation.

An earlier iteration of this design had the gateway forward the host-resolved registration_system_id as a header, and the endpoint reject events belonging to any other organisation. That was dropped for two reasons.

First, it contradicts ADR-0009, which holds that organisation scope is always derived by the server from its own grants and schema: "A request carrying no principal-derived organisation identity has no organisation identity, and no client field supplies one." This request has no principal by design, so from admin-service’s side of the boundary a forwarded header is precisely the client-supplied organisation identity that rule forbids — the same shape as the 2026-07-29 incident that prompted it.

Second, it did not work. A caller addressing admin-service directly could set any value, so the header stopped casual eventId editing and nothing else. It looked like a control without being one, which is worse than having none.

Event carries no published or visible flag today. Until one exists, any event in the database is publicly readable through this endpoint — every organisation, past events, and events not yet open for entry — subject only to the reduced field set above.

This is accepted deliberately and temporarily. The successor is a schema-owned visibility flag on Event, which the endpoint will gate on; that is tracked as a separate feature under Epic #34 and is the ADR-0009-consistent answer, because the scope then comes from the server’s own schema rather than from anything in the request. Until it lands, the reduced field set is the only control, and the decision to publish rests on the field set being genuinely non-sensitive rather than on access restriction.

The rationale and alternatives are recorded in ADR-0010.

Responses:

The customN fields are flat rather than an aligned array. This lets the query build the final DTO in a single constructor expression, and gives the table component a real property name per dynamic column, so column sorting works without custom comparators.

An event may configure up to three custom lists (custom_list_1_id … custom_list_3_id, each with an optional display name in custom_list_N_name). The reference query hard-coded slot 1 as School; the endpoint reports whichever slots are in use and the screen renders a column and a summary per reported slot.

A slot is reported when either:

The second clause is defensive. Imported participants can retain a value in a slot whose list was later cleared from the event; hiding populated data would be worse than showing an extra column.

The column label is the first non-blank of custom_list_N_name, the CustomList entity’s own name, then List N.

event_participant.custom_N_id is a plain foreign key to custom_list_value. Nothing in the schema constrains it to values belonging to the CustomList configured in the event’s matching slot, and in practice it sometimes does not: an event may configure custom_list_1_id = 5 while an individual participant is set by hand to a value from list 6.

Such values are displayed, filterable and counted, exactly like any other. The endpoint reads the value through the participant’s own FK and never checks which list it belongs to.

This is a consequence of one rule, which is load-bearing and must not be "improved" away:

Fetching the canonical list to populate the dropdown would look tidier and would break this case in a way that is hard to spot: the off-list value would still appear in the table and in the summary, but not among the filter options — a visible row that cannot be filtered to, and a summary bucket matching no dropdown entry.

The one cosmetic limit is the column heading. A value borrowed from list 6 is displayed under the heading configured for slot 1, because the heading belongs to the column rather than to the row. Where the two lists are semantically compatible — a school missing from the primary list and picked up from a secondary one — this reads correctly. Where they are not, the heading will be wrong for that row, and the fix belongs in the data rather than in the screen.

The reference query drops a participant whose only order has a null status, because MAX(so.status <> 'C') yields null and fails the = 1 test. The endpoint treats a null status as not cancelled and keeps the participant.

Losing a genuine entry to a data-quality null is worse than showing one extra row on a public list. This is the only intended difference between the screen’s output and the reference query, and it is the first thing to check when reconciling counts between them.

The endpoint returns rows ordered by last name, first name, id. The reference query’s ORDER BY sc.name, … grouping is reproduced in the browser by defaulting the table’s sort to the first configured custom list followed by the name columns — the server ordering is deterministic but not authoritative, because the user can re-sort any column.

The whole roster is returned in one response. The summaries require the complete set regardless, and deriving both the table rows and the pivot counts from one in-memory array means they cannot disagree. A typical schools event is a few hundred to about two thousand rows, which is roughly 30–40 KB gzipped.

A defensive cap of 5 000 rows applies. Beyond it the response is trimmed and truncated is set; the screen shows a warning and hides the summaries, because counts over a truncated set would mislead. The cap is not expected to fire.

A filter toolbar sits above a two-tab view, so that it visibly governs both tabs:

Placing the filters outside the tabs is what makes it obvious that the summaries reflect the current filter rather than the whole event.

Surname, Name, Category, then one column per reported custom list. A missing first name renders as an em dash, as does a null category name — event_category.name is nullable.

All filters combine with AND:

Three behaviours are load-bearing and easy to get wrong:

Filter state is mirrored into the URL query string so organisers can share a pre-filtered view.

One compact table per grouping — by category, and one per configured custom list — each sorted by count descending, with a (not specified) bucket for null values and a total that equals the number of filtered rows.

Every total is an entry count, matching the Entries heading the tables use. Each participant row contributes exactly one entry to exactly one bucket per grouping, so the buckets partition the filtered set and always sum to the number of rows on show.

In practice an entry count and a headcount coincide, because event_participant carries a unique constraint on (event_id, person_id) and every row must have a person — person is @NotNull. The screen does not rely on that, though: it counts rows, and would keep summing correctly if a row without a person ever appeared.

The screen carries a standing note that entries are shown regardless of payment state, and offers a CSV export of the filtered, sorted view together with a print stylesheet for registration-desk use.