# 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.