fete/specs/011-view-attendee-list/spec.md

Feature Specification: View Attendee List

Feature Branch: 011-view-attendee-list Created: 2026-03-08 Status: Draft Input: User description: "der organisator soll die Teilnehmerliste einsehen können, wenn er sich die detail view eines eigenen events anschaut"

Clarifications

Session 2026-03-08

• Q: API-Design — separater Endpoint oder bestehenden erweitern? → A: Separater Endpoint GET /events/{token}/attendees.
• Q: Übermittlung des Organizer-Tokens? → A: Query-Parameter ?organizerToken=<uuid>.
• Q: UI-Platzierung der Attendee-Liste auf der Detail-Seite? → A: Direkt unter dem bestehenden Attendee-Count (vor dem RSVP-Formular).

User Scenarios & Testing (mandatory)

User Story 1 - View Attendee List as Organizer (Priority: P1)

As the organizer of an event, I want to see a list of all attendees (people who RSVPed) when I view my event's detail page, so that I know who is coming.

When the organizer opens the event detail view for an event they created, the page displays a list of attendee names directly below the existing attendee count (before the RSVP form). This list is only visible to the organizer — regular visitors only see the attendee count (existing behavior).

Why this priority: This is the core feature. Without it, organizers have no way to see who signed up for their event.

Independent Test: Can be fully tested by creating an event, submitting RSVPs from other browsers/sessions, then viewing the event detail page with the organizer token. The attendee names should be listed.

Acceptance Scenarios:

1. Given an organizer views their event with 3 RSVPs, When the detail page loads, Then the organizer sees a list showing all 3 attendee names.
2. Given an organizer views their event with 0 RSVPs, When the detail page loads, Then the organizer sees an empty state message indicating no one has RSVPed yet.
3. Given a regular visitor (non-organizer) views the same event, When the detail page loads, Then only the attendee count is shown — no individual names are visible.

---

User Story 2 - Attendee Count Label (Priority: P2)

As the organizer, I want the attendee list to show the total count alongside the names, so I can quickly see how many people are attending at a glance.

Why this priority: Enhances the organizer experience but the count is already visible in the existing detail view, so this is supplementary.

Independent Test: Can be tested by verifying the attendee count displayed next to/above the list matches the number of entries in the list.

Acceptance Scenarios:

1. Given an organizer views their event with 5 RSVPs, When the attendee list is displayed, Then a heading or label shows "5 Attendees" (or equivalent) above the list.
2. Given an organizer views their event with 1 RSVP, When the attendee list is displayed, Then the label uses singular form ("1 Attendee").

---

Edge Cases

• What happens when the organizer token stored locally is invalid or belongs to a different event? The system treats the viewer as a regular visitor and shows the count only — no error is displayed.
• What happens when an attendee name contains special characters or is very long? Names are displayed safely (escaped) and truncated visually if necessary.
• What happens if a large number of attendees (e.g. 100+) have RSVPed? The list remains scrollable and performs well without pagination (events are expected to be small-to-medium scale).

Requirements (mandatory)

Functional Requirements

• FR-001: System MUST provide a dedicated endpoint GET /events/{token}/attendees?organizerToken=<uuid> for organizers to retrieve the attendee list, separate from the public event detail endpoint.
• FR-002: System MUST return each attendee's display name in the attendee list response.
• FR-003: System MUST NOT expose individual attendee names to non-organizer visitors — only the aggregate count is shown (existing behavior preserved).
• FR-004: The attendee list MUST be displayed directly below the attendee count on the event detail view (before the RSVP form) when the viewer is identified as the organizer.
• FR-005: System MUST display an empty state message when no RSVPs exist for the event.
• FR-006: System MUST display the total attendee count as a label alongside the attendee list.
• FR-007: System MUST reject attendee list requests with an invalid or missing organizer token by returning HTTP 403 (no attendee data exposed; frontend degrades gracefully by not rendering the list).

Key Entities

• Attendee (RSVP): A person who has RSVPed to an event. The organizer sees their display name in a list; visitors see only the aggregate count.

Success Criteria (mandatory)

Measurable Outcomes

• SC-001: Organizers can see the full attendee name list within 2 seconds of opening their event detail page.
• SC-002: Non-organizer visitors never see individual attendee names — only the count is visible.
• SC-003: The attendee list correctly reflects all RSVPs submitted for the event, with no missing or duplicate entries.
• SC-004: The feature works correctly on both mobile and desktop viewports.

Assumptions

• The organizer is identified by having a valid organizer token stored on the client. No additional login or authentication mechanism is introduced.
• The attendee list is read-only — the organizer cannot remove or edit attendees from this view.
• Attendee names are displayed in the order they RSVPed (chronological).
• The existing event detail view layout is extended, not replaced, to accommodate the attendee list section.