nitrix
763811fce6
New GET /events/{token}/attendees endpoint returns attendee names when
a valid organizer token is provided (403 otherwise). The frontend
conditionally renders the list below the attendee count for organizers,
silently degrading for visitors.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
69 lines
4.6 KiB
Markdown
69 lines
4.6 KiB
Markdown
# Research: View Attendee List (011)
|
|
|
|
**Date**: 2026-03-08 | **Status**: Complete
|
|
|
|
## 1. Organizer Token Verification Pattern
|
|
|
|
**Decision**: Query parameter `?organizerToken=<uuid>` on the new endpoint.
|
|
|
|
**Rationale**: The project uses token-based access control without persistent sessions. The organizer token is stored in localStorage on the client. Passing it as a query parameter is the simplest approach that fits the existing architecture. The `GET /events/{token}` endpoint already uses path-based token lookup; adding a query parameter for the organizer token keeps the two concerns separate.
|
|
|
|
**Alternatives considered**:
|
|
- Authorization header: More RESTful, but adds complexity without benefit — no auth framework in place, and query params are simpler for this single use case.
|
|
- Embed attendees in existing `GET /events/{token}` response: Rejected per spec clarification — separate endpoint keeps concerns clean and avoids exposing attendee data in the public response.
|
|
|
|
## 2. Endpoint Design
|
|
|
|
**Decision**: `GET /events/{token}/attendees?organizerToken=<uuid>` returns `{ attendees: [{ name: string }] }`.
|
|
|
|
**Rationale**:
|
|
- Nested under `/events/{token}` — resource hierarchy is clear.
|
|
- Returns an object with an `attendees` array (not a raw array) — allows future extension (e.g., adding metadata) without breaking the contract.
|
|
- Each attendee object contains only `name` — minimal data exposure per Privacy by Design.
|
|
- HTTP 403 for invalid/missing organizer token (not 401 — no authentication scheme exists).
|
|
- HTTP 404 if the event token is invalid (consistent with existing `GET /events/{token}`).
|
|
|
|
**Alternatives considered**:
|
|
- Return `{ attendees: [...], count: N }`: Rejected — count is derivable from array length, and already available on the existing event detail endpoint. Avoids redundancy.
|
|
- Include RSVP timestamp: Rejected — spec says chronological order but doesn't require displaying timestamps. Order is implicit in array position.
|
|
|
|
## 3. Backend Implementation Approach
|
|
|
|
**Decision**: New `GetAttendeesUseCase` inbound port, implemented by `RsvpService`. New `findByEventId` method on `RsvpRepository` outbound port.
|
|
|
|
**Rationale**: Follows the established hexagonal architecture pattern exactly. Each use case gets its own inbound port interface. The persistence layer already has `RsvpJpaRepository` with `countByEventId`; adding `findAllByEventIdOrderByIdAsc` is a natural extension (ID order = chronological insertion order).
|
|
|
|
**Alternatives considered**:
|
|
- Add to `GetEventUseCase`: Rejected — violates single responsibility. The event detail endpoint is public; attendee retrieval is organizer-only.
|
|
- Direct repository call in controller: Rejected — violates hexagonal architecture.
|
|
|
|
## 4. Frontend Integration Approach
|
|
|
|
**Decision**: New `AttendeeList.vue` component rendered conditionally in `EventDetailView.vue` when the viewer is the organizer. Fetches attendees via separate API call after event loads.
|
|
|
|
**Rationale**:
|
|
- Separate component keeps EventDetailView manageable (it's already ~300 lines).
|
|
- Separate API call (not bundled with event fetch) — the attendee list is organizer-only; non-organizers never trigger the request.
|
|
- Component placed below attendee count, before RSVP form — matches spec FR-004.
|
|
- Empty state handled within the component (FR-005).
|
|
|
|
**Alternatives considered**:
|
|
- Inline in EventDetailView without separate component: Rejected — view is already complex. A dedicated component improves readability and testability.
|
|
- Fetch attendees in the same call as event details: Not possible — separate endpoint by design.
|
|
|
|
## 5. Error Handling
|
|
|
|
**Decision**: Frontend silently degrades on 403 (does not render attendee list). No error toast or message shown.
|
|
|
|
**Rationale**: Per FR-007, the frontend "degrades gracefully by not rendering the list." If the organizer token is invalid (e.g., localStorage cleared on another device), the user sees the same view as a regular visitor. This is intentional — no confusing error states for edge cases that self-resolve.
|
|
|
|
**Alternatives considered**:
|
|
- Show error message on 403: Rejected — would confuse users who aren't expecting organizer features.
|
|
- Retry with different token: Not applicable — only one token per event in localStorage.
|
|
|
|
## 6. Accessibility Considerations
|
|
|
|
**Decision**: Attendee list rendered as semantic `<ul>` with `<li>` items. Section has a heading for screen readers. Count label uses singular/plural form.
|
|
|
|
**Rationale**: Constitution VI requires WCAG AA compliance, semantic HTML, and keyboard navigation. A list of names is naturally a `<ul>`. The heading provides structure for screen reader navigation.
|