Compare commits
21 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
| d7ed28e036 | |||
| a52d0cd1d3 | |||
| 373f3671f6 | |||
| 8f78c6cd45 | |||
| fe291e36e4 | |||
| e56998b17c | |||
| 1b3eafa8d1 | |||
| 061d507825 | |||
| d79a19ca15 | |||
| 2da36058ae | |||
| 90bfd12bf3 | |||
| 4d6df8d16b | |||
| be1c5062a2 | |||
| d9136481d8 | |||
| e248a2ee06 | |||
| fc77248c38 | |||
| a625e34fe4 | |||
| 4828d06aba | |||
| cac2903807 | |||
|
|
210118bf9a | ||
| 9a78ebd9b0 |
@@ -26,7 +26,7 @@ PASSED=""
|
||||
|
||||
# Run backend tests if Java sources changed
|
||||
if [[ -n "$HAS_BACKEND" ]]; then
|
||||
if OUTPUT=$(cd backend && ./mvnw test -q 2>&1); then
|
||||
if OUTPUT=$(cd backend && ./mvnw verify -q 2>&1); then
|
||||
PASSED+="✓ Backend tests passed. "
|
||||
else
|
||||
# Filter: only [ERROR] lines, skip Maven boilerplate
|
||||
|
||||
94
.claude/skills/merge-pr/SKILL.md
Normal file
94
.claude/skills/merge-pr/SKILL.md
Normal file
@@ -0,0 +1,94 @@
|
||||
---
|
||||
name: merge-pr
|
||||
description: Create a Gitea pull request, monitor CI pipeline status, and merge when green. Use this skill when the user asks to "create a PR", "merge the PR", "ship it", "make it ready to merge", or when you need to open a pull request and wait for CI before merging. Also use when asked to check CI/PR status on Gitea.
|
||||
---
|
||||
|
||||
# Merge PR
|
||||
|
||||
Create a pull request on Gitea, monitor the CI pipeline via the Actions API, and merge once all jobs pass.
|
||||
|
||||
## Why this skill exists
|
||||
|
||||
The Gitea MCP pull request API does not return CI status directly. To know if a PR is ready to merge, you must cross-reference the PR's `head.sha` with the Actions runs API, find the matching run, and check job conclusions. This skill encodes that workflow so it doesn't have to be rediscovered.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
The Gitea MCP tools must be available. The key tools are:
|
||||
|
||||
- `mcp__gitea__pull_request_write` (method: `create`, `merge`)
|
||||
- `mcp__gitea__pull_request_read` (method: `get`)
|
||||
- `mcp__gitea__actions_run_read` (methods: `list_runs`, `list_run_jobs`)
|
||||
|
||||
If these tools are not yet loaded, use ToolSearch to discover and load them before proceeding.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Create the PR
|
||||
|
||||
Use `mcp__gitea__pull_request_write` with method `create`. Include a clear title, body with summary and test plan, head branch, and base branch (usually `master`).
|
||||
|
||||
Save the returned `head.sha` — you need it to find the CI run.
|
||||
|
||||
### 2. Find the CI run for the PR
|
||||
|
||||
The Actions API has no direct "get CI status for PR" call. Instead:
|
||||
|
||||
```
|
||||
mcp__gitea__actions_run_read(method: "list_runs", owner, repo, perPage: 5)
|
||||
```
|
||||
|
||||
Find the run whose `head_sha` matches the PR's `head.sha`. This is the CI run triggered by the push that the PR points to. If the branch was force-pushed or new commits were added, always match against the latest `head.sha` from a fresh `get` on the PR.
|
||||
|
||||
### 3. Monitor job status
|
||||
|
||||
Once you have the run ID:
|
||||
|
||||
```
|
||||
mcp__gitea__actions_run_read(method: "list_run_jobs", owner, repo, run_id: <id>)
|
||||
```
|
||||
|
||||
This returns all jobs with their `status` (queued/in_progress/completed) and `conclusion` (success/failure/skipped/null).
|
||||
|
||||
Present a status table to the user:
|
||||
|
||||
| Job | Status |
|
||||
|-----|--------|
|
||||
| backend-test | success |
|
||||
| frontend-test | in_progress |
|
||||
| frontend-e2e | queued |
|
||||
|
||||
If jobs are still running, wait ~30 seconds and check again. Don't poll in a tight loop.
|
||||
|
||||
### 4. Handle failures
|
||||
|
||||
If any job has `conclusion: failure`:
|
||||
- Use `mcp__gitea__actions_run_read` with method `get_job_log_preview` to fetch the failing job's log
|
||||
- Report the failure to the user with relevant log output
|
||||
- Do NOT attempt to merge
|
||||
|
||||
### 5. Merge when green
|
||||
|
||||
Once all jobs show `conclusion: success` (or `skipped` for conditional jobs like `build-and-publish`):
|
||||
|
||||
```
|
||||
mcp__gitea__pull_request_write(
|
||||
method: "merge",
|
||||
owner, repo,
|
||||
index: <pr_number>,
|
||||
merge_style: "merge",
|
||||
delete_branch: true
|
||||
)
|
||||
```
|
||||
|
||||
Ask the user for confirmation before merging. They may want to review the PR in the web UI first.
|
||||
|
||||
### 6. Post-merge cleanup
|
||||
|
||||
After a successful merge, suggest:
|
||||
- `git checkout master && git pull origin master`
|
||||
- `git branch -d <feature-branch>` (local cleanup)
|
||||
- Tagging a release if appropriate (see `/release` skill)
|
||||
|
||||
## Abbreviated flow
|
||||
|
||||
When the user just wants a quick status check (e.g. "how's the PR?"), skip straight to steps 2-3: find the run by SHA, show the job status table.
|
||||
@@ -79,6 +79,8 @@ jobs:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v6
|
||||
with:
|
||||
fetch-depth: 0
|
||||
|
||||
- name: Parse SemVer tag
|
||||
id: semver
|
||||
@@ -114,3 +116,22 @@ jobs:
|
||||
docker push "${IMAGE}:${{ steps.semver.outputs.minor }}"
|
||||
docker push "${IMAGE}:${{ steps.semver.outputs.major }}"
|
||||
docker push "${IMAGE}:latest"
|
||||
|
||||
- name: Generate changelog
|
||||
id: changelog
|
||||
run: |
|
||||
PREV_TAG=$(git tag --sort=-v:refname | sed -n '2p')
|
||||
if [ -z "$PREV_TAG" ]; then
|
||||
git log --oneline --no-merges > RELEASE_NOTES.md
|
||||
else
|
||||
git log --oneline --no-merges "${PREV_TAG}..HEAD" > RELEASE_NOTES.md
|
||||
fi
|
||||
echo "Container image: \`${IMAGE}:${{ steps.semver.outputs.full }}\`" >> RELEASE_NOTES.md
|
||||
|
||||
- name: Create Gitea release
|
||||
uses: akkuman/gitea-release-action@v1
|
||||
with:
|
||||
tag_name: ${{ github.ref_name }}
|
||||
name: v${{ steps.semver.outputs.full }}
|
||||
body_path: RELEASE_NOTES.md
|
||||
token: ${{ github.token }}
|
||||
|
||||
@@ -33,6 +33,7 @@ Person erstellt via App eine Veranstaltung und schickt seine Freunden irgendwie
|
||||
* Updaten der Veranstaltung
|
||||
* Einsicht angemeldete Gäste, kann bei Bedarf Einträge entfernen
|
||||
* Featureideen:
|
||||
* Organisator kann einstellen, ob Attendee-Namensliste öffentlich auf der Event-Seite sichtbar ist (default: nur für Organisator). Wenn öffentlich, muss im RSVP-Bottom-Sheet eine Warnung angezeigt werden, dass der Name öffentlich sichtbar sein wird.
|
||||
* Link-Previews (OpenGraph Meta-Tags): Generische OG-Tags mit App-Branding (z.B. "fete — Du wurdest eingeladen") damit geteilte Links in WhatsApp/Signal/Telegram hübsch aussehen. Keine Event-Daten an Crawler aus Privacy-Gründen. → Eigene User Story.
|
||||
* Kalender-Integration: .ics-Download + optional webcal:// für Live-Updates bei Änderungen
|
||||
* Änderungen zum ursprünglichen Inhalt (z.b. geändertes datum/ort) werden iwi hervorgehoben
|
||||
@@ -40,6 +41,8 @@ Person erstellt via App eine Veranstaltung und schickt seine Freunden irgendwie
|
||||
* QR Code generieren (z.B. für Plakate/Flyer)
|
||||
* Ablaufdatum als Pflichtfeld, nach dem alle gespeicherten Daten gelöscht werden
|
||||
* Übersichtsliste im LocalStorage: Alle Events die man zugesagt oder gemerkt hat (vgl. spliit)
|
||||
* RSVP editieren: Gast kann seine bestehende Zusage bearbeiten (Name ändern via PUT mit rsvpToken) oder zurückziehen (DELETE mit rsvpToken). Bottom Sheet öffnet sich im Edit-Mode mit pre-filled Name + "Zusage zurückziehen"-Button. Später ergänzen: "Absagen und merken" (Kombination mit 011-bookmark-event). Ausgelagert aus 008-rsvp um den Scope klein zu halten.
|
||||
* Organizer-Gästeliste: Namensliste der Zusagen nur für Organisator sichtbar (über Organizer-Link). Gehört thematisch zu 009-guest-list, nicht zu 008-rsvp.
|
||||
* Sicherheit/Missbrauchsschutz:
|
||||
* Nicht-erratbare Event-Tokens (z.B. UUIDs)
|
||||
* Event-Erstellung ist offen, kein Login/Passwort/Invite-Code nötig
|
||||
@@ -79,3 +82,113 @@ Die folgenden Punkte wurden in Diskussionen bereits geklärt und sind verbindlic
|
||||
* Frontend: Vue 3 (mit Vite als Bundler, TypeScript, Vue Router)
|
||||
* Architekturentscheidungen die NOCH NICHT getroffen wurden (hier darf nichts eigenmächtig entschieden werden!):
|
||||
* (derzeit keine offenen Architekturentscheidungen)
|
||||
|
||||
## Nicht umgesetzte Feature-Ideen (ehemals Specs 009–026)
|
||||
|
||||
### 009 – Gästeliste
|
||||
Organisator sieht alle RSVPs (Name, Status) und kann einzelne Einträge löschen.
|
||||
* Nur mit gültigem Organizer-Token sichtbar
|
||||
* Gäste ohne Token sehen keine Gästeliste
|
||||
* Löschung serverseitig validiert
|
||||
|
||||
### 010 – Event bearbeiten
|
||||
Organisator kann Titel, Beschreibung, Datum, Ort und Ablaufdatum ändern.
|
||||
* Formular vorausgefüllt mit aktuellen Werten
|
||||
* Ablaufdatum muss in der Zukunft liegen
|
||||
* Ohne Organizer-Token kein Edit-UI sichtbar
|
||||
|
||||
### 011 – Event merken/bookmarken
|
||||
Gäste können Events lokal merken, ohne RSVP abzugeben — rein clientseitig via localStorage.
|
||||
* Kein Serverkontakt nötig
|
||||
* Unabhängig vom RSVP-Status
|
||||
* Auch bei abgelaufenen Events möglich
|
||||
|
||||
### 012 – Lokale Event-Übersicht
|
||||
Startseite (`/`) zeigt alle getrackten Events (erstellt, zugesagt, gemerkt) aus localStorage.
|
||||
* Zeigt Titel, Datum, Beziehungstyp (Organisator/Gast/Gemerkt)
|
||||
* Vergangene Events als "beendet" markiert
|
||||
* Einträge können entfernt werden
|
||||
|
||||
### 013 – Kalender-Export
|
||||
.ics-Download (RFC 5545) mit Event-Details, optional webcal:// für Live-Updates.
|
||||
* Stabile UID aus Event-Token (Re-Import aktualisiert statt dupliziert)
|
||||
* Bei Absage: STATUS:CANCELLED im .ics
|
||||
* Kein externer Kalenderservice kontaktiert
|
||||
|
||||
### 014 – Änderungen hervorheben
|
||||
Geänderte Felder werden visuell hervorgehoben, wenn der Gast seit der letzten Änderung nicht mehr auf der Seite war.
|
||||
* Server trackt `last_edited_at` + geänderte Feldnamen
|
||||
* Client speichert `last_seen_at` in localStorage
|
||||
* Privacy-freundlich: kein serverseitiges Read-Tracking
|
||||
|
||||
### 015 – Organisator-Updates
|
||||
Organisator kann Textnachrichten im Event posten (Pinnwand-Stil).
|
||||
* Chronologisch sortiert, löschbar durch Organisator
|
||||
* Nach Ablauf kein Posting mehr möglich
|
||||
* Ohne Organizer-Token kein Compose-UI
|
||||
|
||||
### 016 – Gast-Benachrichtigungen
|
||||
Badge/Indikator bei ungelesenen Organisator-Updates, rein clientseitig via localStorage.
|
||||
* Eigener Timestamp `updates_last_seen_at` (getrennt von Feld-Änderungen)
|
||||
* Kein Indikator beim ersten Besuch
|
||||
* Kein serverseitiges Tracking (Privacy)
|
||||
|
||||
### 017 – QR-Code
|
||||
Event-Seite zeigt QR-Code mit der öffentlichen Event-URL.
|
||||
* Serverseitig generiert (kein externer QR-Service)
|
||||
* Download als SVG oder hochauflösendes PNG
|
||||
* Auch bei abgelaufenen Events verfügbar
|
||||
|
||||
### 018 – Datenlöschung
|
||||
Automatische Löschung aller Event-Daten nach Ablaufdatum (Privacy-Garantie).
|
||||
* Scheduled Job oder Lazy Cleanup bei Zugriff
|
||||
* Löscht Event, RSVPs, Updates, Bilder, Metadaten
|
||||
* Idempotent, kein PII im Log
|
||||
|
||||
### 019 – Instanz-Limit
|
||||
`MAX_ACTIVE_EVENTS` als Env-Variable begrenzt aktive Events für Self-Hoster.
|
||||
* Nur nicht-abgelaufene Events zählen
|
||||
* Unset/leer = unbegrenzt
|
||||
* Serverseitige Durchsetzung bei Event-Erstellung
|
||||
|
||||
### 020 – PWA
|
||||
Web App Manifest + Service Worker für Installierbarkeit und Offline-Caching.
|
||||
* Standalone-Modus ohne Browser-Chrome
|
||||
* Icon + Name auf Home-Screen
|
||||
* Alle Assets selbstgehostet
|
||||
|
||||
### 021 – Farbthemen
|
||||
Organisator wählt bei Erstellung ein vordefiniertes Farbthema für die Event-Seite.
|
||||
* Nur auf der Gast-Seite angewendet (nicht global)
|
||||
* Änderbar beim Bearbeiten
|
||||
* Unabhängig von Dark/Light Mode
|
||||
|
||||
### 022 – Headerbild
|
||||
Organisator sucht Headerbild über integrierte Unsplash-Suche.
|
||||
* Serverseitig geproxied (Client kontaktiert nie Unsplash)
|
||||
* Bild lokal gespeichert + Unsplash-Attribution
|
||||
* Feature deaktiviert wenn kein API-Key konfiguriert
|
||||
|
||||
### 023 – Dark Mode
|
||||
App erkennt `prefers-color-scheme` und bietet manuellen Toggle.
|
||||
* Manuelle Auswahl in localStorage gespeichert
|
||||
* Gilt für globales App-Chrome, nicht Event-Farbthemen
|
||||
* Beide Modi WCAG AA konform
|
||||
|
||||
### 024 – Event absagen
|
||||
Organisator kann Event absagen (mit optionaler Nachricht, Einweg-Transition).
|
||||
* RSVPs werden nach Absage abgelehnt
|
||||
* Absage-Nachricht nachträglich editierbar
|
||||
* Kann nicht rückgängig gemacht werden
|
||||
|
||||
### 025 – Event löschen
|
||||
Organisator löscht Event permanent und unwiderruflich.
|
||||
* Entfernt alle zugehörigen Daten sofort
|
||||
* localStorage-Eintrag wird entfernt, Redirect zu `/`
|
||||
* Funktioniert in jedem Event-Status
|
||||
|
||||
### 026 – 404-Seite
|
||||
Catch-all Route für ungültige Pfade mit "Seite nicht gefunden" und Link zur Startseite.
|
||||
* Folgt dem Design System (Electric Dusk + Sora)
|
||||
* WCAG AA konform
|
||||
* Verhindert leere Seiten bei Fehlnavigation
|
||||
|
||||
@@ -53,6 +53,8 @@ The following skills are available and should be used for their respective purpo
|
||||
## Active Technologies
|
||||
- Java 25 (backend), TypeScript 5.9 (frontend) + Spring Boot 3.5.x, Vue 3, Vue Router 5, openapi-fetch, openapi-typescript (007-view-event)
|
||||
- PostgreSQL (JPA via Spring Data, Liquibase migrations) (007-view-event)
|
||||
- TypeScript 5.9 (frontend only) + Vue 3, Vue Router 5 (existing — no additions) (010-event-list-grouping)
|
||||
- localStorage via `useEventStorage.ts` composable (existing — no changes) (010-event-list-grouping)
|
||||
|
||||
## Recent Changes
|
||||
- 007-view-event: Added Java 25 (backend), TypeScript 5.9 (frontend) + Spring Boot 3.5.x, Vue 3, Vue Router 5, openapi-fetch, openapi-typescript
|
||||
|
||||
@@ -3,12 +3,18 @@ package de.fete.adapter.in.web;
|
||||
import de.fete.adapter.in.web.api.EventsApi;
|
||||
import de.fete.adapter.in.web.model.CreateEventRequest;
|
||||
import de.fete.adapter.in.web.model.CreateEventResponse;
|
||||
import de.fete.adapter.in.web.model.CreateRsvpRequest;
|
||||
import de.fete.adapter.in.web.model.CreateRsvpResponse;
|
||||
import de.fete.adapter.in.web.model.GetEventResponse;
|
||||
import de.fete.application.service.EventNotFoundException;
|
||||
import de.fete.application.service.InvalidTimezoneException;
|
||||
import de.fete.domain.model.CreateEventCommand;
|
||||
import de.fete.domain.model.Event;
|
||||
import de.fete.domain.model.EventToken;
|
||||
import de.fete.domain.model.Rsvp;
|
||||
import de.fete.domain.port.in.CountAttendeesByEventUseCase;
|
||||
import de.fete.domain.port.in.CreateEventUseCase;
|
||||
import de.fete.domain.port.in.CreateRsvpUseCase;
|
||||
import de.fete.domain.port.in.GetEventUseCase;
|
||||
import java.time.Clock;
|
||||
import java.time.DateTimeException;
|
||||
@@ -25,15 +31,21 @@ public class EventController implements EventsApi {
|
||||
|
||||
private final CreateEventUseCase createEventUseCase;
|
||||
private final GetEventUseCase getEventUseCase;
|
||||
private final CreateRsvpUseCase createRsvpUseCase;
|
||||
private final CountAttendeesByEventUseCase countAttendeesByEventUseCase;
|
||||
private final Clock clock;
|
||||
|
||||
/** Creates a new controller with the given use cases and clock. */
|
||||
public EventController(
|
||||
CreateEventUseCase createEventUseCase,
|
||||
GetEventUseCase getEventUseCase,
|
||||
CreateRsvpUseCase createRsvpUseCase,
|
||||
CountAttendeesByEventUseCase countAttendeesByEventUseCase,
|
||||
Clock clock) {
|
||||
this.createEventUseCase = createEventUseCase;
|
||||
this.getEventUseCase = getEventUseCase;
|
||||
this.createRsvpUseCase = createRsvpUseCase;
|
||||
this.countAttendeesByEventUseCase = countAttendeesByEventUseCase;
|
||||
this.clock = clock;
|
||||
}
|
||||
|
||||
@@ -54,8 +66,8 @@ public class EventController implements EventsApi {
|
||||
Event event = createEventUseCase.createEvent(command);
|
||||
|
||||
var response = new CreateEventResponse();
|
||||
response.setEventToken(event.getEventToken());
|
||||
response.setOrganizerToken(event.getOrganizerToken());
|
||||
response.setEventToken(event.getEventToken().value());
|
||||
response.setOrganizerToken(event.getOrganizerToken().value());
|
||||
response.setTitle(event.getTitle());
|
||||
response.setDateTime(event.getDateTime());
|
||||
response.setTimezone(event.getTimezone().getId());
|
||||
@@ -66,23 +78,38 @@ public class EventController implements EventsApi {
|
||||
|
||||
@Override
|
||||
public ResponseEntity<GetEventResponse> getEvent(UUID token) {
|
||||
Event event = getEventUseCase.getByEventToken(token)
|
||||
var eventToken = new de.fete.domain.model.EventToken(token);
|
||||
Event event = getEventUseCase.getByEventToken(eventToken)
|
||||
.orElseThrow(() -> new EventNotFoundException(token));
|
||||
|
||||
var response = new GetEventResponse();
|
||||
response.setEventToken(event.getEventToken());
|
||||
response.setEventToken(event.getEventToken().value());
|
||||
response.setTitle(event.getTitle());
|
||||
response.setDescription(event.getDescription());
|
||||
response.setDateTime(event.getDateTime());
|
||||
response.setTimezone(event.getTimezone().getId());
|
||||
response.setLocation(event.getLocation());
|
||||
response.setAttendeeCount(0);
|
||||
response.setAttendeeCount(
|
||||
(int) countAttendeesByEventUseCase.countByEvent(eventToken));
|
||||
response.setExpired(
|
||||
event.getExpiryDate().isBefore(LocalDate.now(clock)));
|
||||
|
||||
return ResponseEntity.ok(response);
|
||||
}
|
||||
|
||||
@Override
|
||||
public ResponseEntity<CreateRsvpResponse> createRsvp(
|
||||
UUID token, CreateRsvpRequest createRsvpRequest) {
|
||||
var eventToken = new EventToken(token);
|
||||
Rsvp rsvp = createRsvpUseCase.createRsvp(eventToken, createRsvpRequest.getName());
|
||||
|
||||
var response = new CreateRsvpResponse();
|
||||
response.setRsvpToken(rsvp.getRsvpToken().value());
|
||||
response.setName(rsvp.getName());
|
||||
|
||||
return ResponseEntity.status(HttpStatus.CREATED).body(response);
|
||||
}
|
||||
|
||||
private static ZoneId parseTimezone(String timezone) {
|
||||
try {
|
||||
return ZoneId.of(timezone);
|
||||
|
||||
@@ -1,6 +1,8 @@
|
||||
package de.fete.adapter.in.web;
|
||||
|
||||
import de.fete.application.service.EventExpiredException;
|
||||
import de.fete.application.service.EventNotFoundException;
|
||||
import de.fete.application.service.ExpiryDateBeforeEventException;
|
||||
import de.fete.application.service.ExpiryDateInPastException;
|
||||
import de.fete.application.service.InvalidTimezoneException;
|
||||
import java.net.URI;
|
||||
@@ -46,6 +48,19 @@ public class GlobalExceptionHandler extends ResponseEntityExceptionHandler {
|
||||
return handleExceptionInternal(ex, problemDetail, headers, status, request);
|
||||
}
|
||||
|
||||
/** Handles expiry date before event date. */
|
||||
@ExceptionHandler(ExpiryDateBeforeEventException.class)
|
||||
public ResponseEntity<ProblemDetail> handleExpiryDateBeforeEvent(
|
||||
ExpiryDateBeforeEventException ex) {
|
||||
ProblemDetail problemDetail = ProblemDetail.forStatusAndDetail(
|
||||
HttpStatus.BAD_REQUEST, ex.getMessage());
|
||||
problemDetail.setTitle("Invalid Expiry Date");
|
||||
problemDetail.setType(URI.create("urn:problem-type:expiry-date-before-event"));
|
||||
return ResponseEntity.badRequest()
|
||||
.contentType(MediaType.APPLICATION_PROBLEM_JSON)
|
||||
.body(problemDetail);
|
||||
}
|
||||
|
||||
/** Handles expiry date validation failures. */
|
||||
@ExceptionHandler(ExpiryDateInPastException.class)
|
||||
public ResponseEntity<ProblemDetail> handleExpiryDateInPast(
|
||||
@@ -59,6 +74,19 @@ public class GlobalExceptionHandler extends ResponseEntityExceptionHandler {
|
||||
.body(problemDetail);
|
||||
}
|
||||
|
||||
/** Handles RSVP on expired event. */
|
||||
@ExceptionHandler(EventExpiredException.class)
|
||||
public ResponseEntity<ProblemDetail> handleEventExpired(
|
||||
EventExpiredException ex) {
|
||||
ProblemDetail problemDetail = ProblemDetail.forStatusAndDetail(
|
||||
HttpStatus.CONFLICT, ex.getMessage());
|
||||
problemDetail.setTitle("Event Expired");
|
||||
problemDetail.setType(URI.create("urn:problem-type:event-expired"));
|
||||
return ResponseEntity.status(HttpStatus.CONFLICT)
|
||||
.contentType(MediaType.APPLICATION_PROBLEM_JSON)
|
||||
.body(problemDetail);
|
||||
}
|
||||
|
||||
/** Handles event not found. */
|
||||
@ExceptionHandler(EventNotFoundException.class)
|
||||
public ResponseEntity<ProblemDetail> handleEventNotFound(
|
||||
|
||||
@@ -1,10 +1,11 @@
|
||||
package de.fete.adapter.out.persistence;
|
||||
|
||||
import de.fete.domain.model.Event;
|
||||
import de.fete.domain.model.EventToken;
|
||||
import de.fete.domain.model.OrganizerToken;
|
||||
import de.fete.domain.port.out.EventRepository;
|
||||
import java.time.ZoneId;
|
||||
import java.util.Optional;
|
||||
import java.util.UUID;
|
||||
import org.springframework.stereotype.Repository;
|
||||
|
||||
/** Persistence adapter implementing the EventRepository outbound port. */
|
||||
@@ -26,15 +27,15 @@ public class EventPersistenceAdapter implements EventRepository {
|
||||
}
|
||||
|
||||
@Override
|
||||
public Optional<Event> findByEventToken(UUID eventToken) {
|
||||
return jpaRepository.findByEventToken(eventToken).map(this::toDomain);
|
||||
public Optional<Event> findByEventToken(EventToken eventToken) {
|
||||
return jpaRepository.findByEventToken(eventToken.value()).map(this::toDomain);
|
||||
}
|
||||
|
||||
private EventJpaEntity toEntity(Event event) {
|
||||
var entity = new EventJpaEntity();
|
||||
entity.setId(event.getId());
|
||||
entity.setEventToken(event.getEventToken());
|
||||
entity.setOrganizerToken(event.getOrganizerToken());
|
||||
entity.setEventToken(event.getEventToken().value());
|
||||
entity.setOrganizerToken(event.getOrganizerToken().value());
|
||||
entity.setTitle(event.getTitle());
|
||||
entity.setDescription(event.getDescription());
|
||||
entity.setDateTime(event.getDateTime());
|
||||
@@ -48,8 +49,8 @@ public class EventPersistenceAdapter implements EventRepository {
|
||||
private Event toDomain(EventJpaEntity entity) {
|
||||
var event = new Event();
|
||||
event.setId(entity.getId());
|
||||
event.setEventToken(entity.getEventToken());
|
||||
event.setOrganizerToken(entity.getOrganizerToken());
|
||||
event.setEventToken(new EventToken(entity.getEventToken()));
|
||||
event.setOrganizerToken(new OrganizerToken(entity.getOrganizerToken()));
|
||||
event.setTitle(entity.getTitle());
|
||||
event.setDescription(entity.getDescription());
|
||||
event.setDateTime(entity.getDateTime());
|
||||
|
||||
@@ -0,0 +1,68 @@
|
||||
package de.fete.adapter.out.persistence;
|
||||
|
||||
import jakarta.persistence.Column;
|
||||
import jakarta.persistence.Entity;
|
||||
import jakarta.persistence.GeneratedValue;
|
||||
import jakarta.persistence.GenerationType;
|
||||
import jakarta.persistence.Id;
|
||||
import jakarta.persistence.Table;
|
||||
import java.util.UUID;
|
||||
|
||||
/** JPA entity mapping to the rsvps table. */
|
||||
@Entity
|
||||
@Table(name = "rsvps")
|
||||
public class RsvpJpaEntity {
|
||||
|
||||
@Id
|
||||
@GeneratedValue(strategy = GenerationType.IDENTITY)
|
||||
private Long id;
|
||||
|
||||
@Column(name = "rsvp_token", nullable = false, unique = true)
|
||||
private UUID rsvpToken;
|
||||
|
||||
@Column(name = "event_id", nullable = false)
|
||||
private Long eventId;
|
||||
|
||||
@Column(nullable = false, length = 100)
|
||||
private String name;
|
||||
|
||||
/** Returns the internal database ID. */
|
||||
public Long getId() {
|
||||
return id;
|
||||
}
|
||||
|
||||
/** Sets the internal database ID. */
|
||||
public void setId(Long id) {
|
||||
this.id = id;
|
||||
}
|
||||
|
||||
/** Returns the RSVP token. */
|
||||
public UUID getRsvpToken() {
|
||||
return rsvpToken;
|
||||
}
|
||||
|
||||
/** Sets the RSVP token. */
|
||||
public void setRsvpToken(UUID rsvpToken) {
|
||||
this.rsvpToken = rsvpToken;
|
||||
}
|
||||
|
||||
/** Returns the event ID. */
|
||||
public Long getEventId() {
|
||||
return eventId;
|
||||
}
|
||||
|
||||
/** Sets the event ID. */
|
||||
public void setEventId(Long eventId) {
|
||||
this.eventId = eventId;
|
||||
}
|
||||
|
||||
/** Returns the guest's display name. */
|
||||
public String getName() {
|
||||
return name;
|
||||
}
|
||||
|
||||
/** Sets the guest's display name. */
|
||||
public void setName(String name) {
|
||||
this.name = name;
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,14 @@
|
||||
package de.fete.adapter.out.persistence;
|
||||
|
||||
import java.util.UUID;
|
||||
import org.springframework.data.jpa.repository.JpaRepository;
|
||||
|
||||
/** Spring Data JPA repository for RSVP entities. */
|
||||
public interface RsvpJpaRepository extends JpaRepository<RsvpJpaEntity, Long> {
|
||||
|
||||
/** Finds an RSVP by its token. */
|
||||
java.util.Optional<RsvpJpaEntity> findByRsvpToken(UUID rsvpToken);
|
||||
|
||||
/** Counts RSVPs for the given event. */
|
||||
long countByEventId(Long eventId);
|
||||
}
|
||||
@@ -0,0 +1,48 @@
|
||||
package de.fete.adapter.out.persistence;
|
||||
|
||||
import de.fete.domain.model.Rsvp;
|
||||
import de.fete.domain.model.RsvpToken;
|
||||
import de.fete.domain.port.out.RsvpRepository;
|
||||
import org.springframework.stereotype.Repository;
|
||||
|
||||
/** Persistence adapter implementing the RsvpRepository outbound port. */
|
||||
@Repository
|
||||
public class RsvpPersistenceAdapter implements RsvpRepository {
|
||||
|
||||
private final RsvpJpaRepository jpaRepository;
|
||||
|
||||
/** Creates a new adapter with the given JPA repository. */
|
||||
public RsvpPersistenceAdapter(RsvpJpaRepository jpaRepository) {
|
||||
this.jpaRepository = jpaRepository;
|
||||
}
|
||||
|
||||
@Override
|
||||
public Rsvp save(Rsvp rsvp) {
|
||||
RsvpJpaEntity entity = toEntity(rsvp);
|
||||
RsvpJpaEntity saved = jpaRepository.save(entity);
|
||||
return toDomain(saved);
|
||||
}
|
||||
|
||||
@Override
|
||||
public long countByEventId(Long eventId) {
|
||||
return jpaRepository.countByEventId(eventId);
|
||||
}
|
||||
|
||||
private RsvpJpaEntity toEntity(Rsvp rsvp) {
|
||||
var entity = new RsvpJpaEntity();
|
||||
entity.setId(rsvp.getId());
|
||||
entity.setRsvpToken(rsvp.getRsvpToken().value());
|
||||
entity.setEventId(rsvp.getEventId());
|
||||
entity.setName(rsvp.getName());
|
||||
return entity;
|
||||
}
|
||||
|
||||
private Rsvp toDomain(RsvpJpaEntity entity) {
|
||||
var rsvp = new Rsvp();
|
||||
rsvp.setId(entity.getId());
|
||||
rsvp.setRsvpToken(new RsvpToken(entity.getRsvpToken()));
|
||||
rsvp.setEventId(entity.getEventId());
|
||||
rsvp.setName(entity.getName());
|
||||
return rsvp;
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,12 @@
|
||||
package de.fete.application.service;
|
||||
|
||||
import java.util.UUID;
|
||||
|
||||
/** Thrown when an RSVP is attempted on an expired event. */
|
||||
public class EventExpiredException extends RuntimeException {
|
||||
|
||||
/** Creates a new exception for the given event token. */
|
||||
public EventExpiredException(UUID eventToken) {
|
||||
super("Event has expired: " + eventToken);
|
||||
}
|
||||
}
|
||||
@@ -2,6 +2,8 @@ package de.fete.application.service;
|
||||
|
||||
import de.fete.domain.model.CreateEventCommand;
|
||||
import de.fete.domain.model.Event;
|
||||
import de.fete.domain.model.EventToken;
|
||||
import de.fete.domain.model.OrganizerToken;
|
||||
import de.fete.domain.port.in.CreateEventUseCase;
|
||||
import de.fete.domain.port.in.GetEventUseCase;
|
||||
import de.fete.domain.port.out.EventRepository;
|
||||
@@ -9,7 +11,6 @@ import java.time.Clock;
|
||||
import java.time.LocalDate;
|
||||
import java.time.OffsetDateTime;
|
||||
import java.util.Optional;
|
||||
import java.util.UUID;
|
||||
import org.springframework.stereotype.Service;
|
||||
|
||||
/** Application service implementing event creation and retrieval. */
|
||||
@@ -31,9 +32,13 @@ public class EventService implements CreateEventUseCase, GetEventUseCase {
|
||||
throw new ExpiryDateInPastException(command.expiryDate());
|
||||
}
|
||||
|
||||
if (!command.expiryDate().isAfter(command.dateTime().toLocalDate())) {
|
||||
throw new ExpiryDateBeforeEventException(command.expiryDate(), command.dateTime());
|
||||
}
|
||||
|
||||
var event = new Event();
|
||||
event.setEventToken(UUID.randomUUID());
|
||||
event.setOrganizerToken(UUID.randomUUID());
|
||||
event.setEventToken(EventToken.generate());
|
||||
event.setOrganizerToken(OrganizerToken.generate());
|
||||
event.setTitle(command.title());
|
||||
event.setDescription(command.description());
|
||||
event.setDateTime(command.dateTime());
|
||||
@@ -46,7 +51,7 @@ public class EventService implements CreateEventUseCase, GetEventUseCase {
|
||||
}
|
||||
|
||||
@Override
|
||||
public Optional<Event> getByEventToken(UUID eventToken) {
|
||||
public Optional<Event> getByEventToken(EventToken eventToken) {
|
||||
return eventRepository.findByEventToken(eventToken);
|
||||
}
|
||||
}
|
||||
|
||||
@@ -0,0 +1,13 @@
|
||||
package de.fete.application.service;
|
||||
|
||||
import java.time.LocalDate;
|
||||
import java.time.OffsetDateTime;
|
||||
|
||||
/** Thrown when an event's expiry date is not after the event date. */
|
||||
public class ExpiryDateBeforeEventException extends RuntimeException {
|
||||
|
||||
/** Creates a new exception for the given dates. */
|
||||
public ExpiryDateBeforeEventException(LocalDate expiryDate, OffsetDateTime dateTime) {
|
||||
super("Expiry date " + expiryDate + " must be after event date " + dateTime.toLocalDate());
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,56 @@
|
||||
package de.fete.application.service;
|
||||
|
||||
import de.fete.domain.model.Event;
|
||||
import de.fete.domain.model.EventToken;
|
||||
import de.fete.domain.model.Rsvp;
|
||||
import de.fete.domain.model.RsvpToken;
|
||||
import de.fete.domain.port.in.CountAttendeesByEventUseCase;
|
||||
import de.fete.domain.port.in.CreateRsvpUseCase;
|
||||
import de.fete.domain.port.out.EventRepository;
|
||||
import de.fete.domain.port.out.RsvpRepository;
|
||||
import java.time.Clock;
|
||||
import java.time.LocalDate;
|
||||
import org.springframework.stereotype.Service;
|
||||
|
||||
/** Application service implementing RSVP creation. */
|
||||
@Service
|
||||
public class RsvpService implements CreateRsvpUseCase, CountAttendeesByEventUseCase {
|
||||
|
||||
private final EventRepository eventRepository;
|
||||
private final RsvpRepository rsvpRepository;
|
||||
private final Clock clock;
|
||||
|
||||
/** Creates a new RsvpService. */
|
||||
public RsvpService(
|
||||
EventRepository eventRepository,
|
||||
RsvpRepository rsvpRepository,
|
||||
Clock clock) {
|
||||
this.eventRepository = eventRepository;
|
||||
this.rsvpRepository = rsvpRepository;
|
||||
this.clock = clock;
|
||||
}
|
||||
|
||||
@Override
|
||||
public Rsvp createRsvp(EventToken eventToken, String name) {
|
||||
Event event = eventRepository.findByEventToken(eventToken)
|
||||
.orElseThrow(() -> new EventNotFoundException(eventToken.value()));
|
||||
|
||||
if (!event.getExpiryDate().isAfter(LocalDate.now(clock))) {
|
||||
throw new EventExpiredException(eventToken.value());
|
||||
}
|
||||
|
||||
var rsvp = new Rsvp();
|
||||
rsvp.setRsvpToken(RsvpToken.generate());
|
||||
rsvp.setEventId(event.getId());
|
||||
rsvp.setName(name.strip());
|
||||
|
||||
return rsvpRepository.save(rsvp);
|
||||
}
|
||||
|
||||
@Override
|
||||
public long countByEvent(EventToken eventToken) {
|
||||
Event event = eventRepository.findByEventToken(eventToken)
|
||||
.orElseThrow(() -> new EventNotFoundException(eventToken.value()));
|
||||
return rsvpRepository.countByEventId(event.getId());
|
||||
}
|
||||
}
|
||||
@@ -3,14 +3,13 @@ package de.fete.domain.model;
|
||||
import java.time.LocalDate;
|
||||
import java.time.OffsetDateTime;
|
||||
import java.time.ZoneId;
|
||||
import java.util.UUID;
|
||||
|
||||
/** Domain entity representing an event. */
|
||||
public class Event {
|
||||
|
||||
private Long id;
|
||||
private UUID eventToken;
|
||||
private UUID organizerToken;
|
||||
private EventToken eventToken;
|
||||
private OrganizerToken organizerToken;
|
||||
private String title;
|
||||
private String description;
|
||||
private OffsetDateTime dateTime;
|
||||
@@ -29,23 +28,23 @@ public class Event {
|
||||
this.id = id;
|
||||
}
|
||||
|
||||
/** Returns the public event token (UUID). */
|
||||
public UUID getEventToken() {
|
||||
/** Returns the public event token. */
|
||||
public EventToken getEventToken() {
|
||||
return eventToken;
|
||||
}
|
||||
|
||||
/** Sets the public event token. */
|
||||
public void setEventToken(UUID eventToken) {
|
||||
public void setEventToken(EventToken eventToken) {
|
||||
this.eventToken = eventToken;
|
||||
}
|
||||
|
||||
/** Returns the secret organizer token (UUID). */
|
||||
public UUID getOrganizerToken() {
|
||||
/** Returns the secret organizer token. */
|
||||
public OrganizerToken getOrganizerToken() {
|
||||
return organizerToken;
|
||||
}
|
||||
|
||||
/** Sets the secret organizer token. */
|
||||
public void setOrganizerToken(UUID organizerToken) {
|
||||
public void setOrganizerToken(OrganizerToken organizerToken) {
|
||||
this.organizerToken = organizerToken;
|
||||
}
|
||||
|
||||
|
||||
18
backend/src/main/java/de/fete/domain/model/EventToken.java
Normal file
18
backend/src/main/java/de/fete/domain/model/EventToken.java
Normal file
@@ -0,0 +1,18 @@
|
||||
package de.fete.domain.model;
|
||||
|
||||
import java.util.Objects;
|
||||
import java.util.UUID;
|
||||
|
||||
/** Type-safe wrapper for the public event token. */
|
||||
public record EventToken(UUID value) {
|
||||
|
||||
/** Validates that the token value is not null. */
|
||||
public EventToken {
|
||||
Objects.requireNonNull(value, "eventToken must not be null");
|
||||
}
|
||||
|
||||
/** Generates a new random event token. */
|
||||
public static EventToken generate() {
|
||||
return new EventToken(UUID.randomUUID());
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,18 @@
|
||||
package de.fete.domain.model;
|
||||
|
||||
import java.util.Objects;
|
||||
import java.util.UUID;
|
||||
|
||||
/** Type-safe wrapper for the secret organizer token. */
|
||||
public record OrganizerToken(UUID value) {
|
||||
|
||||
/** Validates that the token value is not null. */
|
||||
public OrganizerToken {
|
||||
Objects.requireNonNull(value, "organizerToken must not be null");
|
||||
}
|
||||
|
||||
/** Generates a new random organizer token. */
|
||||
public static OrganizerToken generate() {
|
||||
return new OrganizerToken(UUID.randomUUID());
|
||||
}
|
||||
}
|
||||
50
backend/src/main/java/de/fete/domain/model/Rsvp.java
Normal file
50
backend/src/main/java/de/fete/domain/model/Rsvp.java
Normal file
@@ -0,0 +1,50 @@
|
||||
package de.fete.domain.model;
|
||||
|
||||
/** Domain entity representing an RSVP. */
|
||||
public class Rsvp {
|
||||
|
||||
private Long id;
|
||||
private RsvpToken rsvpToken;
|
||||
private Long eventId;
|
||||
private String name;
|
||||
|
||||
/** Returns the internal database ID. */
|
||||
public Long getId() {
|
||||
return id;
|
||||
}
|
||||
|
||||
/** Sets the internal database ID. */
|
||||
public void setId(Long id) {
|
||||
this.id = id;
|
||||
}
|
||||
|
||||
/** Returns the RSVP token. */
|
||||
public RsvpToken getRsvpToken() {
|
||||
return rsvpToken;
|
||||
}
|
||||
|
||||
/** Sets the RSVP token. */
|
||||
public void setRsvpToken(RsvpToken rsvpToken) {
|
||||
this.rsvpToken = rsvpToken;
|
||||
}
|
||||
|
||||
/** Returns the event ID this RSVP belongs to. */
|
||||
public Long getEventId() {
|
||||
return eventId;
|
||||
}
|
||||
|
||||
/** Sets the event ID. */
|
||||
public void setEventId(Long eventId) {
|
||||
this.eventId = eventId;
|
||||
}
|
||||
|
||||
/** Returns the guest's display name. */
|
||||
public String getName() {
|
||||
return name;
|
||||
}
|
||||
|
||||
/** Sets the guest's display name. */
|
||||
public void setName(String name) {
|
||||
this.name = name;
|
||||
}
|
||||
}
|
||||
18
backend/src/main/java/de/fete/domain/model/RsvpToken.java
Normal file
18
backend/src/main/java/de/fete/domain/model/RsvpToken.java
Normal file
@@ -0,0 +1,18 @@
|
||||
package de.fete.domain.model;
|
||||
|
||||
import java.util.Objects;
|
||||
import java.util.UUID;
|
||||
|
||||
/** Type-safe wrapper for the RSVP token. */
|
||||
public record RsvpToken(UUID value) {
|
||||
|
||||
/** Validates that the token value is not null. */
|
||||
public RsvpToken {
|
||||
Objects.requireNonNull(value, "rsvpToken must not be null");
|
||||
}
|
||||
|
||||
/** Generates a new random RSVP token. */
|
||||
public static RsvpToken generate() {
|
||||
return new RsvpToken(UUID.randomUUID());
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,10 @@
|
||||
package de.fete.domain.port.in;
|
||||
|
||||
import de.fete.domain.model.EventToken;
|
||||
|
||||
/** Inbound port for counting attendees of an event. */
|
||||
public interface CountAttendeesByEventUseCase {
|
||||
|
||||
/** Counts the number of confirmed attendees for the given event. */
|
||||
long countByEvent(EventToken eventToken);
|
||||
}
|
||||
@@ -0,0 +1,11 @@
|
||||
package de.fete.domain.port.in;
|
||||
|
||||
import de.fete.domain.model.EventToken;
|
||||
import de.fete.domain.model.Rsvp;
|
||||
|
||||
/** Inbound port for creating a new RSVP. */
|
||||
public interface CreateRsvpUseCase {
|
||||
|
||||
/** Creates an RSVP for the given event and guest name. */
|
||||
Rsvp createRsvp(EventToken eventToken, String name);
|
||||
}
|
||||
@@ -1,12 +1,12 @@
|
||||
package de.fete.domain.port.in;
|
||||
|
||||
import de.fete.domain.model.Event;
|
||||
import de.fete.domain.model.EventToken;
|
||||
import java.util.Optional;
|
||||
import java.util.UUID;
|
||||
|
||||
/** Inbound port for retrieving a public event by its token. */
|
||||
public interface GetEventUseCase {
|
||||
|
||||
/** Finds an event by its public event token. */
|
||||
Optional<Event> getByEventToken(UUID eventToken);
|
||||
Optional<Event> getByEventToken(EventToken eventToken);
|
||||
}
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
package de.fete.domain.port.out;
|
||||
|
||||
import de.fete.domain.model.Event;
|
||||
import de.fete.domain.model.EventToken;
|
||||
import java.util.Optional;
|
||||
import java.util.UUID;
|
||||
|
||||
/** Outbound port for persisting and retrieving events. */
|
||||
public interface EventRepository {
|
||||
@@ -11,5 +11,5 @@ public interface EventRepository {
|
||||
Event save(Event event);
|
||||
|
||||
/** Finds an event by its public event token. */
|
||||
Optional<Event> findByEventToken(UUID eventToken);
|
||||
Optional<Event> findByEventToken(EventToken eventToken);
|
||||
}
|
||||
|
||||
@@ -0,0 +1,13 @@
|
||||
package de.fete.domain.port.out;
|
||||
|
||||
import de.fete.domain.model.Rsvp;
|
||||
|
||||
/** Outbound port for persisting and querying RSVPs. */
|
||||
public interface RsvpRepository {
|
||||
|
||||
/** Persists the given RSVP and returns it with generated fields populated. */
|
||||
Rsvp save(Rsvp rsvp);
|
||||
|
||||
/** Counts the number of RSVPs for the given event. */
|
||||
long countByEventId(Long eventId);
|
||||
}
|
||||
@@ -0,0 +1,36 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<databaseChangeLog
|
||||
xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
|
||||
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
|
||||
xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
|
||||
http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-latest.xsd">
|
||||
|
||||
<changeSet id="003-create-rsvps-table" author="fete">
|
||||
<createTable tableName="rsvps">
|
||||
<column name="id" type="bigserial" autoIncrement="true">
|
||||
<constraints primaryKey="true" nullable="false"/>
|
||||
</column>
|
||||
<column name="rsvp_token" type="uuid">
|
||||
<constraints nullable="false" unique="true"/>
|
||||
</column>
|
||||
<column name="event_id" type="bigint">
|
||||
<constraints nullable="false"
|
||||
foreignKeyName="fk_rsvps_event_id"
|
||||
references="events(id)"
|
||||
deleteCascade="true"/>
|
||||
</column>
|
||||
<column name="name" type="varchar(100)">
|
||||
<constraints nullable="false"/>
|
||||
</column>
|
||||
</createTable>
|
||||
|
||||
<createIndex tableName="rsvps" indexName="idx_rsvps_event_id">
|
||||
<column name="event_id"/>
|
||||
</createIndex>
|
||||
|
||||
<createIndex tableName="rsvps" indexName="idx_rsvps_rsvp_token">
|
||||
<column name="rsvp_token"/>
|
||||
</createIndex>
|
||||
</changeSet>
|
||||
|
||||
</databaseChangeLog>
|
||||
@@ -8,5 +8,6 @@
|
||||
<include file="db/changelog/000-baseline.xml"/>
|
||||
<include file="db/changelog/001-create-events-table.xml"/>
|
||||
<include file="db/changelog/002-add-timezone-column.xml"/>
|
||||
<include file="db/changelog/003-create-rsvps-table.xml"/>
|
||||
|
||||
</databaseChangeLog>
|
||||
|
||||
@@ -37,6 +37,52 @@ paths:
|
||||
schema:
|
||||
$ref: "#/components/schemas/ValidationProblemDetail"
|
||||
|
||||
/events/{token}/rsvps:
|
||||
post:
|
||||
operationId: createRsvp
|
||||
summary: Submit an RSVP for an event
|
||||
tags:
|
||||
- events
|
||||
parameters:
|
||||
- name: token
|
||||
in: path
|
||||
required: true
|
||||
schema:
|
||||
type: string
|
||||
format: uuid
|
||||
description: Public event token
|
||||
requestBody:
|
||||
required: true
|
||||
content:
|
||||
application/json:
|
||||
schema:
|
||||
$ref: "#/components/schemas/CreateRsvpRequest"
|
||||
responses:
|
||||
"201":
|
||||
description: RSVP created successfully
|
||||
content:
|
||||
application/json:
|
||||
schema:
|
||||
$ref: "#/components/schemas/CreateRsvpResponse"
|
||||
"400":
|
||||
description: Validation failed (e.g. blank name)
|
||||
content:
|
||||
application/problem+json:
|
||||
schema:
|
||||
$ref: "#/components/schemas/ValidationProblemDetail"
|
||||
"404":
|
||||
description: Event not found
|
||||
content:
|
||||
application/problem+json:
|
||||
schema:
|
||||
$ref: "#/components/schemas/ProblemDetail"
|
||||
"409":
|
||||
description: Event has expired — RSVPs no longer accepted
|
||||
content:
|
||||
application/problem+json:
|
||||
schema:
|
||||
$ref: "#/components/schemas/ProblemDetail"
|
||||
|
||||
/events/{token}:
|
||||
get:
|
||||
operationId: getEvent
|
||||
@@ -182,6 +228,34 @@ components:
|
||||
description: Whether the event's expiry date has passed
|
||||
example: false
|
||||
|
||||
CreateRsvpRequest:
|
||||
type: object
|
||||
required:
|
||||
- name
|
||||
properties:
|
||||
name:
|
||||
type: string
|
||||
minLength: 1
|
||||
maxLength: 100
|
||||
description: Guest's display name
|
||||
example: "Max Mustermann"
|
||||
|
||||
CreateRsvpResponse:
|
||||
type: object
|
||||
required:
|
||||
- rsvpToken
|
||||
- name
|
||||
properties:
|
||||
rsvpToken:
|
||||
type: string
|
||||
format: uuid
|
||||
description: Token identifying this RSVP (store client-side for future updates)
|
||||
example: "d4e5f6a7-b8c9-0123-4567-890abcdef012"
|
||||
name:
|
||||
type: string
|
||||
description: Guest's display name as stored
|
||||
example: "Max Mustermann"
|
||||
|
||||
ProblemDetail:
|
||||
type: object
|
||||
properties:
|
||||
|
||||
@@ -60,4 +60,9 @@ class HexagonalArchitectureTest {
|
||||
static final ArchRule persistenceMustNotDependOnWeb = noClasses()
|
||||
.that().resideInAPackage("de.fete.adapter.out.persistence..")
|
||||
.should().dependOnClassesThat().resideInAPackage("de.fete.adapter.in.web..");
|
||||
|
||||
@ArchTest
|
||||
static final ArchRule webAdapterMustNotDependOnOutboundPorts = noClasses()
|
||||
.that().resideInAPackage("de.fete.adapter.in.web..")
|
||||
.should().dependOnClassesThat().resideInAPackage("de.fete.domain.port.out..");
|
||||
}
|
||||
|
||||
@@ -11,8 +11,12 @@ import com.fasterxml.jackson.databind.ObjectMapper;
|
||||
import de.fete.TestcontainersConfig;
|
||||
import de.fete.adapter.in.web.model.CreateEventRequest;
|
||||
import de.fete.adapter.in.web.model.CreateEventResponse;
|
||||
import de.fete.adapter.in.web.model.CreateRsvpRequest;
|
||||
import de.fete.adapter.in.web.model.CreateRsvpResponse;
|
||||
import de.fete.adapter.out.persistence.EventJpaEntity;
|
||||
import de.fete.adapter.out.persistence.EventJpaRepository;
|
||||
import de.fete.adapter.out.persistence.RsvpJpaEntity;
|
||||
import de.fete.adapter.out.persistence.RsvpJpaRepository;
|
||||
import java.time.LocalDate;
|
||||
import java.time.OffsetDateTime;
|
||||
import java.time.ZoneOffset;
|
||||
@@ -39,6 +43,9 @@ class EventControllerIntegrationTest {
|
||||
@Autowired
|
||||
private EventJpaRepository jpaRepository;
|
||||
|
||||
@Autowired
|
||||
private RsvpJpaRepository rsvpJpaRepository;
|
||||
|
||||
// --- Create Event tests ---
|
||||
|
||||
@Test
|
||||
@@ -49,7 +56,7 @@ class EventControllerIntegrationTest {
|
||||
.dateTime(OffsetDateTime.of(2026, 6, 15, 20, 0, 0, 0, ZoneOffset.ofHours(2)))
|
||||
.timezone("Europe/Berlin")
|
||||
.location("Berlin")
|
||||
.expiryDate(LocalDate.now().plusDays(30));
|
||||
.expiryDate(LocalDate.of(2026, 6, 16));
|
||||
|
||||
var result = mockMvc.perform(post("/api/events")
|
||||
.contentType(MediaType.APPLICATION_JSON)
|
||||
@@ -85,7 +92,7 @@ class EventControllerIntegrationTest {
|
||||
.title("Minimal Event")
|
||||
.dateTime(OffsetDateTime.of(2026, 6, 15, 20, 0, 0, 0, ZoneOffset.ofHours(2)))
|
||||
.timezone("UTC")
|
||||
.expiryDate(LocalDate.now().plusDays(30));
|
||||
.expiryDate(LocalDate.of(2026, 6, 16));
|
||||
|
||||
var result = mockMvc.perform(post("/api/events")
|
||||
.contentType(MediaType.APPLICATION_JSON)
|
||||
@@ -108,10 +115,12 @@ class EventControllerIntegrationTest {
|
||||
|
||||
@Test
|
||||
void createEventMissingTitleReturns400() throws Exception {
|
||||
long countBefore = jpaRepository.count();
|
||||
|
||||
var request = new CreateEventRequest()
|
||||
.dateTime(OffsetDateTime.of(2026, 6, 15, 20, 0, 0, 0, ZoneOffset.ofHours(2)))
|
||||
.timezone("Europe/Berlin")
|
||||
.expiryDate(LocalDate.now().plusDays(30));
|
||||
.expiryDate(LocalDate.of(2026, 6, 16));
|
||||
|
||||
mockMvc.perform(post("/api/events")
|
||||
.contentType(MediaType.APPLICATION_JSON)
|
||||
@@ -120,14 +129,18 @@ class EventControllerIntegrationTest {
|
||||
.andExpect(content().contentTypeCompatibleWith("application/problem+json"))
|
||||
.andExpect(jsonPath("$.title").value("Validation Failed"))
|
||||
.andExpect(jsonPath("$.fieldErrors").isArray());
|
||||
|
||||
assertThat(jpaRepository.count()).isEqualTo(countBefore);
|
||||
}
|
||||
|
||||
@Test
|
||||
void createEventMissingDateTimeReturns400() throws Exception {
|
||||
long countBefore = jpaRepository.count();
|
||||
|
||||
var request = new CreateEventRequest()
|
||||
.title("No Date")
|
||||
.timezone("Europe/Berlin")
|
||||
.expiryDate(LocalDate.now().plusDays(30));
|
||||
.expiryDate(LocalDate.of(2026, 6, 16));
|
||||
|
||||
mockMvc.perform(post("/api/events")
|
||||
.contentType(MediaType.APPLICATION_JSON)
|
||||
@@ -135,10 +148,14 @@ class EventControllerIntegrationTest {
|
||||
.andExpect(status().isBadRequest())
|
||||
.andExpect(content().contentTypeCompatibleWith("application/problem+json"))
|
||||
.andExpect(jsonPath("$.fieldErrors").isArray());
|
||||
|
||||
assertThat(jpaRepository.count()).isEqualTo(countBefore);
|
||||
}
|
||||
|
||||
@Test
|
||||
void createEventMissingExpiryDateReturns400() throws Exception {
|
||||
long countBefore = jpaRepository.count();
|
||||
|
||||
var request = new CreateEventRequest()
|
||||
.title("No Expiry")
|
||||
.dateTime(OffsetDateTime.of(2026, 6, 15, 20, 0, 0, 0, ZoneOffset.ofHours(2)))
|
||||
@@ -150,10 +167,14 @@ class EventControllerIntegrationTest {
|
||||
.andExpect(status().isBadRequest())
|
||||
.andExpect(content().contentTypeCompatibleWith("application/problem+json"))
|
||||
.andExpect(jsonPath("$.fieldErrors").isArray());
|
||||
|
||||
assertThat(jpaRepository.count()).isEqualTo(countBefore);
|
||||
}
|
||||
|
||||
@Test
|
||||
void createEventExpiryDateInPastReturns400() throws Exception {
|
||||
long countBefore = jpaRepository.count();
|
||||
|
||||
var request = new CreateEventRequest()
|
||||
.title("Past Expiry")
|
||||
.dateTime(OffsetDateTime.of(2026, 6, 15, 20, 0, 0, 0, ZoneOffset.ofHours(2)))
|
||||
@@ -166,10 +187,14 @@ class EventControllerIntegrationTest {
|
||||
.andExpect(status().isBadRequest())
|
||||
.andExpect(content().contentTypeCompatibleWith("application/problem+json"))
|
||||
.andExpect(jsonPath("$.type").value("urn:problem-type:expiry-date-in-past"));
|
||||
|
||||
assertThat(jpaRepository.count()).isEqualTo(countBefore);
|
||||
}
|
||||
|
||||
@Test
|
||||
void createEventExpiryDateTodayReturns400() throws Exception {
|
||||
long countBefore = jpaRepository.count();
|
||||
|
||||
var request = new CreateEventRequest()
|
||||
.title("Today Expiry")
|
||||
.dateTime(OffsetDateTime.of(2026, 6, 15, 20, 0, 0, 0, ZoneOffset.ofHours(2)))
|
||||
@@ -182,6 +207,48 @@ class EventControllerIntegrationTest {
|
||||
.andExpect(status().isBadRequest())
|
||||
.andExpect(content().contentTypeCompatibleWith("application/problem+json"))
|
||||
.andExpect(jsonPath("$.type").value("urn:problem-type:expiry-date-in-past"));
|
||||
|
||||
assertThat(jpaRepository.count()).isEqualTo(countBefore);
|
||||
}
|
||||
|
||||
@Test
|
||||
void createEventExpiryDateBeforeEventDateReturns400() throws Exception {
|
||||
long countBefore = jpaRepository.count();
|
||||
|
||||
var request = new CreateEventRequest()
|
||||
.title("Bad Expiry")
|
||||
.dateTime(OffsetDateTime.of(2026, 6, 15, 20, 0, 0, 0, ZoneOffset.ofHours(2)))
|
||||
.timezone("Europe/Berlin")
|
||||
.expiryDate(LocalDate.of(2026, 6, 10));
|
||||
|
||||
mockMvc.perform(post("/api/events")
|
||||
.contentType(MediaType.APPLICATION_JSON)
|
||||
.content(objectMapper.writeValueAsString(request)))
|
||||
.andExpect(status().isBadRequest())
|
||||
.andExpect(content().contentTypeCompatibleWith("application/problem+json"))
|
||||
.andExpect(jsonPath("$.type").value("urn:problem-type:expiry-date-before-event"));
|
||||
|
||||
assertThat(jpaRepository.count()).isEqualTo(countBefore);
|
||||
}
|
||||
|
||||
@Test
|
||||
void createEventExpiryDateSameAsEventDateReturns400() throws Exception {
|
||||
long countBefore = jpaRepository.count();
|
||||
|
||||
var request = new CreateEventRequest()
|
||||
.title("Same Day Expiry")
|
||||
.dateTime(OffsetDateTime.of(2026, 6, 15, 20, 0, 0, 0, ZoneOffset.ofHours(2)))
|
||||
.timezone("Europe/Berlin")
|
||||
.expiryDate(LocalDate.of(2026, 6, 15));
|
||||
|
||||
mockMvc.perform(post("/api/events")
|
||||
.contentType(MediaType.APPLICATION_JSON)
|
||||
.content(objectMapper.writeValueAsString(request)))
|
||||
.andExpect(status().isBadRequest())
|
||||
.andExpect(content().contentTypeCompatibleWith("application/problem+json"))
|
||||
.andExpect(jsonPath("$.type").value("urn:problem-type:expiry-date-before-event"));
|
||||
|
||||
assertThat(jpaRepository.count()).isEqualTo(countBefore);
|
||||
}
|
||||
|
||||
@Test
|
||||
@@ -190,7 +257,7 @@ class EventControllerIntegrationTest {
|
||||
.title("")
|
||||
.dateTime(OffsetDateTime.of(2026, 6, 15, 20, 0, 0, 0, ZoneOffset.ofHours(2)))
|
||||
.timezone("Europe/Berlin")
|
||||
.expiryDate(LocalDate.now().plusDays(30));
|
||||
.expiryDate(LocalDate.of(2026, 6, 16));
|
||||
|
||||
mockMvc.perform(post("/api/events")
|
||||
.contentType(MediaType.APPLICATION_JSON)
|
||||
@@ -201,11 +268,13 @@ class EventControllerIntegrationTest {
|
||||
|
||||
@Test
|
||||
void createEventWithInvalidTimezoneReturns400() throws Exception {
|
||||
long countBefore = jpaRepository.count();
|
||||
|
||||
var request = new CreateEventRequest()
|
||||
.title("Bad TZ")
|
||||
.dateTime(OffsetDateTime.of(2026, 6, 15, 20, 0, 0, 0, ZoneOffset.ofHours(2)))
|
||||
.timezone("Not/A/Zone")
|
||||
.expiryDate(LocalDate.now().plusDays(30));
|
||||
.expiryDate(LocalDate.of(2026, 6, 16));
|
||||
|
||||
mockMvc.perform(post("/api/events")
|
||||
.contentType(MediaType.APPLICATION_JSON)
|
||||
@@ -213,6 +282,8 @@ class EventControllerIntegrationTest {
|
||||
.andExpect(status().isBadRequest())
|
||||
.andExpect(content().contentTypeCompatibleWith("application/problem+json"))
|
||||
.andExpect(jsonPath("$.type").value("urn:problem-type:invalid-timezone"));
|
||||
|
||||
assertThat(jpaRepository.count()).isEqualTo(countBefore);
|
||||
}
|
||||
|
||||
// --- GET /events/{token} tests ---
|
||||
@@ -268,6 +339,106 @@ class EventControllerIntegrationTest {
|
||||
.andExpect(jsonPath("$.expired").value(true));
|
||||
}
|
||||
|
||||
// --- RSVP tests ---
|
||||
|
||||
@Test
|
||||
void createRsvpReturns201WithToken() throws Exception {
|
||||
EventJpaEntity event = seedEvent(
|
||||
"RSVP Event", "Join us!", "Europe/Berlin",
|
||||
"Berlin", LocalDate.now().plusDays(30));
|
||||
|
||||
var request = new CreateRsvpRequest().name("Max Mustermann");
|
||||
|
||||
var result = mockMvc.perform(post("/api/events/" + event.getEventToken() + "/rsvps")
|
||||
.contentType(MediaType.APPLICATION_JSON)
|
||||
.content(objectMapper.writeValueAsString(request)))
|
||||
.andExpect(status().isCreated())
|
||||
.andExpect(jsonPath("$.rsvpToken").isNotEmpty())
|
||||
.andExpect(jsonPath("$.name").value("Max Mustermann"))
|
||||
.andReturn();
|
||||
|
||||
var response = objectMapper.readValue(
|
||||
result.getResponse().getContentAsString(), CreateRsvpResponse.class);
|
||||
|
||||
RsvpJpaEntity persisted = rsvpJpaRepository
|
||||
.findByRsvpToken(response.getRsvpToken()).orElseThrow();
|
||||
assertThat(persisted.getName()).isEqualTo("Max Mustermann");
|
||||
assertThat(persisted.getEventId()).isEqualTo(event.getId());
|
||||
}
|
||||
|
||||
@Test
|
||||
void createRsvpWithBlankNameReturns400() throws Exception {
|
||||
EventJpaEntity event = seedEvent(
|
||||
"RSVP Event", null, "Europe/Berlin",
|
||||
null, LocalDate.now().plusDays(30));
|
||||
long countBefore = rsvpJpaRepository.count();
|
||||
|
||||
var request = new CreateRsvpRequest().name("");
|
||||
|
||||
mockMvc.perform(post("/api/events/" + event.getEventToken() + "/rsvps")
|
||||
.contentType(MediaType.APPLICATION_JSON)
|
||||
.content(objectMapper.writeValueAsString(request)))
|
||||
.andExpect(status().isBadRequest())
|
||||
.andExpect(content().contentTypeCompatibleWith("application/problem+json"));
|
||||
|
||||
assertThat(rsvpJpaRepository.count()).isEqualTo(countBefore);
|
||||
}
|
||||
|
||||
@Test
|
||||
void attendeeCountIncreasesAfterRsvp() throws Exception {
|
||||
EventJpaEntity event = seedEvent(
|
||||
"Count Event", null, "Europe/Berlin",
|
||||
null, LocalDate.now().plusDays(30));
|
||||
|
||||
mockMvc.perform(get("/api/events/" + event.getEventToken()))
|
||||
.andExpect(jsonPath("$.attendeeCount").value(0));
|
||||
|
||||
var request = new CreateRsvpRequest().name("First Guest");
|
||||
|
||||
mockMvc.perform(post("/api/events/" + event.getEventToken() + "/rsvps")
|
||||
.contentType(MediaType.APPLICATION_JSON)
|
||||
.content(objectMapper.writeValueAsString(request)))
|
||||
.andExpect(status().isCreated());
|
||||
|
||||
mockMvc.perform(get("/api/events/" + event.getEventToken()))
|
||||
.andExpect(jsonPath("$.attendeeCount").value(1));
|
||||
}
|
||||
|
||||
@Test
|
||||
void createRsvpForUnknownEventReturns404() throws Exception {
|
||||
long countBefore = rsvpJpaRepository.count();
|
||||
|
||||
var request = new CreateRsvpRequest().name("Ghost");
|
||||
|
||||
mockMvc.perform(post("/api/events/" + UUID.randomUUID() + "/rsvps")
|
||||
.contentType(MediaType.APPLICATION_JSON)
|
||||
.content(objectMapper.writeValueAsString(request)))
|
||||
.andExpect(status().isNotFound())
|
||||
.andExpect(content().contentTypeCompatibleWith("application/problem+json"))
|
||||
.andExpect(jsonPath("$.type").value("urn:problem-type:event-not-found"));
|
||||
|
||||
assertThat(rsvpJpaRepository.count()).isEqualTo(countBefore);
|
||||
}
|
||||
|
||||
@Test
|
||||
void createRsvpForExpiredEventReturns409() throws Exception {
|
||||
EventJpaEntity event = seedEvent(
|
||||
"Expired Party", null, "Europe/Berlin",
|
||||
null, LocalDate.now().minusDays(1));
|
||||
long countBefore = rsvpJpaRepository.count();
|
||||
|
||||
var request = new CreateRsvpRequest().name("Late Guest");
|
||||
|
||||
mockMvc.perform(post("/api/events/" + event.getEventToken() + "/rsvps")
|
||||
.contentType(MediaType.APPLICATION_JSON)
|
||||
.content(objectMapper.writeValueAsString(request)))
|
||||
.andExpect(status().isConflict())
|
||||
.andExpect(content().contentTypeCompatibleWith("application/problem+json"))
|
||||
.andExpect(jsonPath("$.type").value("urn:problem-type:event-expired"));
|
||||
|
||||
assertThat(rsvpJpaRepository.count()).isEqualTo(countBefore);
|
||||
}
|
||||
|
||||
private EventJpaEntity seedEvent(
|
||||
String title, String description, String timezone,
|
||||
String location, LocalDate expiryDate) {
|
||||
|
||||
@@ -4,13 +4,14 @@ import static org.assertj.core.api.Assertions.assertThat;
|
||||
|
||||
import de.fete.TestcontainersConfig;
|
||||
import de.fete.domain.model.Event;
|
||||
import de.fete.domain.model.EventToken;
|
||||
import de.fete.domain.model.OrganizerToken;
|
||||
import de.fete.domain.port.out.EventRepository;
|
||||
import java.time.LocalDate;
|
||||
import java.time.OffsetDateTime;
|
||||
import java.time.ZoneId;
|
||||
import java.time.ZoneOffset;
|
||||
import java.util.Optional;
|
||||
import java.util.UUID;
|
||||
import org.junit.jupiter.api.Test;
|
||||
import org.springframework.beans.factory.annotation.Autowired;
|
||||
import org.springframework.boot.test.context.SpringBootTest;
|
||||
@@ -47,7 +48,7 @@ class EventPersistenceAdapterTest {
|
||||
|
||||
@Test
|
||||
void findByUnknownEventTokenReturnsEmpty() {
|
||||
Optional<Event> found = eventRepository.findByEventToken(UUID.randomUUID());
|
||||
Optional<Event> found = eventRepository.findByEventToken(EventToken.generate());
|
||||
|
||||
assertThat(found).isEmpty();
|
||||
}
|
||||
@@ -61,8 +62,8 @@ class EventPersistenceAdapterTest {
|
||||
OffsetDateTime.of(2026, 3, 4, 12, 0, 0, 0, ZoneOffset.UTC);
|
||||
|
||||
var event = new Event();
|
||||
event.setEventToken(UUID.randomUUID());
|
||||
event.setOrganizerToken(UUID.randomUUID());
|
||||
event.setEventToken(EventToken.generate());
|
||||
event.setOrganizerToken(OrganizerToken.generate());
|
||||
event.setTitle("Full Event");
|
||||
event.setDescription("A detailed description");
|
||||
event.setDateTime(dateTime);
|
||||
@@ -87,8 +88,8 @@ class EventPersistenceAdapterTest {
|
||||
|
||||
private Event buildEvent() {
|
||||
var event = new Event();
|
||||
event.setEventToken(UUID.randomUUID());
|
||||
event.setOrganizerToken(UUID.randomUUID());
|
||||
event.setEventToken(EventToken.generate());
|
||||
event.setOrganizerToken(OrganizerToken.generate());
|
||||
event.setTitle("Test Event");
|
||||
event.setDescription("Test description");
|
||||
event.setDateTime(OffsetDateTime.now().plusDays(7));
|
||||
|
||||
@@ -9,15 +9,14 @@ import static org.mockito.Mockito.when;
|
||||
|
||||
import de.fete.domain.model.CreateEventCommand;
|
||||
import de.fete.domain.model.Event;
|
||||
import de.fete.domain.model.EventToken;
|
||||
import de.fete.domain.port.out.EventRepository;
|
||||
import java.time.Clock;
|
||||
import java.time.Instant;
|
||||
import java.time.LocalDate;
|
||||
import java.time.OffsetDateTime;
|
||||
import java.time.ZoneId;
|
||||
import java.time.ZoneOffset;
|
||||
import java.util.Optional;
|
||||
import java.util.UUID;
|
||||
import org.junit.jupiter.api.BeforeEach;
|
||||
import org.junit.jupiter.api.Test;
|
||||
import org.junit.jupiter.api.extension.ExtendWith;
|
||||
@@ -32,6 +31,7 @@ class EventServiceTest {
|
||||
private static final Instant FIXED_INSTANT =
|
||||
LocalDate.of(2026, 3, 5).atStartOfDay(ZONE).toInstant();
|
||||
private static final Clock FIXED_CLOCK = Clock.fixed(FIXED_INSTANT, ZONE);
|
||||
private static final LocalDate TODAY = LocalDate.ofInstant(FIXED_INSTANT, ZONE);
|
||||
|
||||
@Mock
|
||||
private EventRepository eventRepository;
|
||||
@@ -51,21 +51,21 @@ class EventServiceTest {
|
||||
var command = new CreateEventCommand(
|
||||
"Birthday Party",
|
||||
"Come celebrate!",
|
||||
OffsetDateTime.of(2026, 6, 15, 20, 0, 0, 0, ZoneOffset.ofHours(2)),
|
||||
ZoneId.of("Europe/Berlin"),
|
||||
TODAY.plusDays(90).atStartOfDay(ZONE).toOffsetDateTime(),
|
||||
ZONE,
|
||||
"Berlin",
|
||||
LocalDate.of(2026, 7, 15)
|
||||
TODAY.plusDays(120)
|
||||
);
|
||||
|
||||
Event result = eventService.createEvent(command);
|
||||
|
||||
assertThat(result.getTitle()).isEqualTo("Birthday Party");
|
||||
assertThat(result.getDescription()).isEqualTo("Come celebrate!");
|
||||
assertThat(result.getTimezone()).isEqualTo(ZoneId.of("Europe/Berlin"));
|
||||
assertThat(result.getTimezone()).isEqualTo(ZONE);
|
||||
assertThat(result.getLocation()).isEqualTo("Berlin");
|
||||
assertThat(result.getEventToken()).isNotNull();
|
||||
assertThat(result.getOrganizerToken()).isNotNull();
|
||||
assertThat(result.getCreatedAt()).isEqualTo(OffsetDateTime.now(FIXED_CLOCK));
|
||||
assertThat(result.getCreatedAt()).isEqualTo(OffsetDateTime.ofInstant(FIXED_INSTANT, ZONE));
|
||||
}
|
||||
|
||||
@Test
|
||||
@@ -75,8 +75,8 @@ class EventServiceTest {
|
||||
|
||||
var command = new CreateEventCommand(
|
||||
"Test", null,
|
||||
OffsetDateTime.now(FIXED_CLOCK).plusDays(1), ZONE, null,
|
||||
LocalDate.now(FIXED_CLOCK).plusDays(30)
|
||||
TODAY.plusDays(10).atStartOfDay(ZONE).toOffsetDateTime(), ZONE, null,
|
||||
TODAY.plusDays(11)
|
||||
);
|
||||
|
||||
eventService.createEvent(command);
|
||||
@@ -90,8 +90,8 @@ class EventServiceTest {
|
||||
void expiryDateTodayThrowsException() {
|
||||
var command = new CreateEventCommand(
|
||||
"Test", null,
|
||||
OffsetDateTime.now(FIXED_CLOCK).plusDays(1), ZONE, null,
|
||||
LocalDate.now(FIXED_CLOCK)
|
||||
TODAY.plusDays(10).atStartOfDay(ZONE).toOffsetDateTime(), ZONE, null,
|
||||
TODAY
|
||||
);
|
||||
|
||||
assertThatThrownBy(() -> eventService.createEvent(command))
|
||||
@@ -102,8 +102,8 @@ class EventServiceTest {
|
||||
void expiryDateInPastThrowsException() {
|
||||
var command = new CreateEventCommand(
|
||||
"Test", null,
|
||||
OffsetDateTime.now(FIXED_CLOCK).plusDays(1), ZONE, null,
|
||||
LocalDate.now(FIXED_CLOCK).minusDays(5)
|
||||
TODAY.plusDays(10).atStartOfDay(ZONE).toOffsetDateTime(), ZONE, null,
|
||||
TODAY.minusDays(5)
|
||||
);
|
||||
|
||||
assertThatThrownBy(() -> eventService.createEvent(command))
|
||||
@@ -117,20 +117,63 @@ class EventServiceTest {
|
||||
|
||||
var command = new CreateEventCommand(
|
||||
"Test", null,
|
||||
OffsetDateTime.now(FIXED_CLOCK).plusDays(1), ZONE, null,
|
||||
LocalDate.now(FIXED_CLOCK).plusDays(1)
|
||||
TODAY.plusDays(1).atStartOfDay(ZONE).toOffsetDateTime(), ZONE, null,
|
||||
TODAY.plusDays(2)
|
||||
);
|
||||
|
||||
Event result = eventService.createEvent(command);
|
||||
|
||||
assertThat(result.getExpiryDate()).isEqualTo(LocalDate.of(2026, 3, 6));
|
||||
assertThat(result.getExpiryDate()).isEqualTo(TODAY.plusDays(2));
|
||||
}
|
||||
|
||||
@Test
|
||||
void expiryDateSameAsEventDateThrowsException() {
|
||||
var command = new CreateEventCommand(
|
||||
"Test", null,
|
||||
TODAY.plusDays(10).atStartOfDay(ZONE).toOffsetDateTime(),
|
||||
ZONE, null,
|
||||
TODAY.plusDays(10)
|
||||
);
|
||||
|
||||
assertThatThrownBy(() -> eventService.createEvent(command))
|
||||
.isInstanceOf(ExpiryDateBeforeEventException.class);
|
||||
}
|
||||
|
||||
@Test
|
||||
void expiryDateBeforeEventDateThrowsException() {
|
||||
var command = new CreateEventCommand(
|
||||
"Test", null,
|
||||
TODAY.plusDays(10).atStartOfDay(ZONE).toOffsetDateTime(),
|
||||
ZONE, null,
|
||||
TODAY.plusDays(5)
|
||||
);
|
||||
|
||||
assertThatThrownBy(() -> eventService.createEvent(command))
|
||||
.isInstanceOf(ExpiryDateBeforeEventException.class);
|
||||
}
|
||||
|
||||
@Test
|
||||
void expiryDateDayAfterEventDateSucceeds() {
|
||||
when(eventRepository.save(any(Event.class)))
|
||||
.thenAnswer(invocation -> invocation.getArgument(0));
|
||||
|
||||
var command = new CreateEventCommand(
|
||||
"Test", null,
|
||||
TODAY.plusDays(10).atStartOfDay(ZONE).toOffsetDateTime(),
|
||||
ZONE, null,
|
||||
TODAY.plusDays(11)
|
||||
);
|
||||
|
||||
Event result = eventService.createEvent(command);
|
||||
|
||||
assertThat(result.getExpiryDate()).isEqualTo(TODAY.plusDays(11));
|
||||
}
|
||||
|
||||
// --- GetEventUseCase tests (T004) ---
|
||||
|
||||
@Test
|
||||
void getByEventTokenReturnsEvent() {
|
||||
UUID token = UUID.randomUUID();
|
||||
EventToken token = EventToken.generate();
|
||||
var event = new Event();
|
||||
event.setEventToken(token);
|
||||
event.setTitle("Found Event");
|
||||
@@ -145,7 +188,7 @@ class EventServiceTest {
|
||||
|
||||
@Test
|
||||
void getByEventTokenReturnsEmptyForUnknownToken() {
|
||||
UUID token = UUID.randomUUID();
|
||||
EventToken token = EventToken.generate();
|
||||
when(eventRepository.findByEventToken(token))
|
||||
.thenReturn(Optional.empty());
|
||||
|
||||
@@ -163,9 +206,9 @@ class EventServiceTest {
|
||||
|
||||
var command = new CreateEventCommand(
|
||||
"Test", null,
|
||||
OffsetDateTime.now(FIXED_CLOCK).plusDays(1),
|
||||
TODAY.plusDays(10).atStartOfDay(ZONE).toOffsetDateTime(),
|
||||
ZoneId.of("America/New_York"), null,
|
||||
LocalDate.now(FIXED_CLOCK).plusDays(30)
|
||||
TODAY.plusDays(11)
|
||||
);
|
||||
|
||||
Event result = eventService.createEvent(command);
|
||||
|
||||
@@ -0,0 +1,137 @@
|
||||
package de.fete.application.service;
|
||||
|
||||
import static org.assertj.core.api.Assertions.assertThat;
|
||||
import static org.assertj.core.api.Assertions.assertThatThrownBy;
|
||||
import static org.mockito.ArgumentMatchers.any;
|
||||
import static org.mockito.Mockito.verify;
|
||||
import static org.mockito.Mockito.when;
|
||||
|
||||
import de.fete.domain.model.Event;
|
||||
import de.fete.domain.model.EventToken;
|
||||
import de.fete.domain.model.OrganizerToken;
|
||||
import de.fete.domain.model.Rsvp;
|
||||
import de.fete.domain.port.out.EventRepository;
|
||||
import de.fete.domain.port.out.RsvpRepository;
|
||||
import java.time.Clock;
|
||||
import java.time.Instant;
|
||||
import java.time.LocalDate;
|
||||
import java.time.OffsetDateTime;
|
||||
import java.time.ZoneId;
|
||||
import java.time.ZoneOffset;
|
||||
import java.util.Optional;
|
||||
import org.junit.jupiter.api.BeforeEach;
|
||||
import org.junit.jupiter.api.Test;
|
||||
import org.junit.jupiter.api.extension.ExtendWith;
|
||||
import org.mockito.ArgumentCaptor;
|
||||
import org.mockito.Mock;
|
||||
import org.mockito.junit.jupiter.MockitoExtension;
|
||||
|
||||
@ExtendWith(MockitoExtension.class)
|
||||
class RsvpServiceTest {
|
||||
|
||||
private static final ZoneId ZONE = ZoneId.of("Europe/Berlin");
|
||||
private static final Instant NOW = Instant.parse("2026-03-08T12:00:00Z");
|
||||
private static final Clock FIXED_CLOCK = Clock.fixed(NOW, ZONE);
|
||||
private static final LocalDate TODAY = LocalDate.ofInstant(NOW, ZONE);
|
||||
|
||||
@Mock
|
||||
private EventRepository eventRepository;
|
||||
|
||||
@Mock
|
||||
private RsvpRepository rsvpRepository;
|
||||
|
||||
private RsvpService rsvpService;
|
||||
|
||||
@BeforeEach
|
||||
void setUp() {
|
||||
rsvpService = new RsvpService(eventRepository, rsvpRepository, FIXED_CLOCK);
|
||||
}
|
||||
|
||||
@Test
|
||||
void createRsvpSucceedsForActiveEvent() {
|
||||
Event event = buildActiveEvent();
|
||||
EventToken token = event.getEventToken();
|
||||
when(eventRepository.findByEventToken(token)).thenReturn(Optional.of(event));
|
||||
when(rsvpRepository.save(any(Rsvp.class)))
|
||||
.thenAnswer(invocation -> invocation.getArgument(0));
|
||||
|
||||
Rsvp result = rsvpService.createRsvp(token, "Max Mustermann");
|
||||
|
||||
assertThat(result.getName()).isEqualTo("Max Mustermann");
|
||||
assertThat(result.getRsvpToken()).isNotNull();
|
||||
assertThat(result.getEventId()).isEqualTo(event.getId());
|
||||
}
|
||||
|
||||
@Test
|
||||
void createRsvpPersistsViaRepository() {
|
||||
Event event = buildActiveEvent();
|
||||
EventToken token = event.getEventToken();
|
||||
when(eventRepository.findByEventToken(token)).thenReturn(Optional.of(event));
|
||||
when(rsvpRepository.save(any(Rsvp.class)))
|
||||
.thenAnswer(invocation -> invocation.getArgument(0));
|
||||
|
||||
rsvpService.createRsvp(token, "Test Guest");
|
||||
|
||||
ArgumentCaptor<Rsvp> captor = ArgumentCaptor.forClass(Rsvp.class);
|
||||
verify(rsvpRepository).save(captor.capture());
|
||||
assertThat(captor.getValue().getName()).isEqualTo("Test Guest");
|
||||
assertThat(captor.getValue().getEventId()).isEqualTo(event.getId());
|
||||
}
|
||||
|
||||
@Test
|
||||
void createRsvpThrowsWhenEventNotFound() {
|
||||
EventToken token = EventToken.generate();
|
||||
when(eventRepository.findByEventToken(token)).thenReturn(Optional.empty());
|
||||
|
||||
assertThatThrownBy(() -> rsvpService.createRsvp(token, "Guest"))
|
||||
.isInstanceOf(EventNotFoundException.class);
|
||||
}
|
||||
|
||||
@Test
|
||||
void createRsvpTrimsName() {
|
||||
Event event = buildActiveEvent();
|
||||
EventToken token = event.getEventToken();
|
||||
when(eventRepository.findByEventToken(token)).thenReturn(Optional.of(event));
|
||||
when(rsvpRepository.save(any(Rsvp.class)))
|
||||
.thenAnswer(invocation -> invocation.getArgument(0));
|
||||
|
||||
Rsvp result = rsvpService.createRsvp(token, " Max ");
|
||||
|
||||
assertThat(result.getName()).isEqualTo("Max");
|
||||
}
|
||||
|
||||
@Test
|
||||
void createRsvpThrowsWhenEventExpired() {
|
||||
var event = buildActiveEvent();
|
||||
event.setExpiryDate(TODAY.minusDays(1));
|
||||
EventToken token = event.getEventToken();
|
||||
when(eventRepository.findByEventToken(token)).thenReturn(Optional.of(event));
|
||||
|
||||
assertThatThrownBy(() -> rsvpService.createRsvp(token, "Late Guest"))
|
||||
.isInstanceOf(EventExpiredException.class);
|
||||
}
|
||||
|
||||
@Test
|
||||
void createRsvpThrowsWhenEventExpiresToday() {
|
||||
var event = buildActiveEvent();
|
||||
event.setExpiryDate(TODAY);
|
||||
EventToken token = event.getEventToken();
|
||||
when(eventRepository.findByEventToken(token)).thenReturn(Optional.of(event));
|
||||
|
||||
assertThatThrownBy(() -> rsvpService.createRsvp(token, "Late Guest"))
|
||||
.isInstanceOf(EventExpiredException.class);
|
||||
}
|
||||
|
||||
private Event buildActiveEvent() {
|
||||
var event = new Event();
|
||||
event.setId(1L);
|
||||
event.setEventToken(EventToken.generate());
|
||||
event.setOrganizerToken(OrganizerToken.generate());
|
||||
event.setTitle("Test Event");
|
||||
event.setDateTime(OffsetDateTime.of(2026, 6, 15, 20, 0, 0, 0, ZoneOffset.ofHours(2)));
|
||||
event.setTimezone(ZONE);
|
||||
event.setExpiryDate(TODAY.plusDays(30));
|
||||
event.setCreatedAt(OffsetDateTime.now());
|
||||
return event;
|
||||
}
|
||||
}
|
||||
185
frontend/e2e/event-rsvp.spec.ts
Normal file
185
frontend/e2e/event-rsvp.spec.ts
Normal file
@@ -0,0 +1,185 @@
|
||||
import { http, HttpResponse } from 'msw'
|
||||
import { test, expect } from './msw-setup'
|
||||
|
||||
const fullEvent = {
|
||||
eventToken: 'a1b2c3d4-e5f6-7890-abcd-ef1234567890',
|
||||
title: 'Summer BBQ',
|
||||
description: 'Bring your own drinks!',
|
||||
dateTime: '2026-03-15T20:00:00+01:00',
|
||||
timezone: 'Europe/Berlin',
|
||||
location: 'Central Park, NYC',
|
||||
attendeeCount: 12,
|
||||
expired: false,
|
||||
}
|
||||
|
||||
test.describe('US1: RSVP submission flow', () => {
|
||||
test('submits RSVP, updates attendee count, and persists in localStorage', async ({ page, network }) => {
|
||||
network.use(
|
||||
http.get('*/api/events/:token', () => {
|
||||
return HttpResponse.json(fullEvent)
|
||||
}),
|
||||
http.post('*/api/events/:token/rsvps', () => {
|
||||
return HttpResponse.json(
|
||||
{ rsvpToken: 'd4e5f6a7-b8c9-0123-4567-890abcdef012', name: 'Max Mustermann' },
|
||||
{ status: 201 },
|
||||
)
|
||||
}),
|
||||
)
|
||||
|
||||
await page.goto(`/events/${fullEvent.eventToken}`)
|
||||
|
||||
// CTA is visible
|
||||
const cta = page.getByRole('button', { name: "I'm attending" })
|
||||
await expect(cta).toBeVisible()
|
||||
|
||||
// Open bottom sheet
|
||||
await cta.click()
|
||||
const dialog = page.getByRole('dialog', { name: 'RSVP' })
|
||||
await expect(dialog).toBeVisible()
|
||||
|
||||
// Fill name and submit
|
||||
await dialog.getByLabel('Your name').fill('Max Mustermann')
|
||||
await dialog.getByRole('button', { name: 'Count me in' }).click()
|
||||
|
||||
// Bottom sheet closes, status bar appears
|
||||
await expect(dialog).not.toBeVisible()
|
||||
await expect(page.getByText("You're attending!")).toBeVisible()
|
||||
await expect(cta).not.toBeVisible()
|
||||
|
||||
// Attendee count incremented
|
||||
await expect(page.getByText('13')).toBeVisible()
|
||||
|
||||
// Verify localStorage
|
||||
const stored = await page.evaluate(() => {
|
||||
const raw = localStorage.getItem('fete:events')
|
||||
return raw ? JSON.parse(raw) : null
|
||||
})
|
||||
expect(stored).toEqual(
|
||||
expect.arrayContaining([
|
||||
expect.objectContaining({
|
||||
eventToken: 'a1b2c3d4-e5f6-7890-abcd-ef1234567890',
|
||||
rsvpToken: 'd4e5f6a7-b8c9-0123-4567-890abcdef012',
|
||||
rsvpName: 'Max Mustermann',
|
||||
}),
|
||||
]),
|
||||
)
|
||||
})
|
||||
|
||||
test('shows validation error when name is empty', async ({ page, network }) => {
|
||||
network.use(
|
||||
http.get('*/api/events/:token', () => {
|
||||
return HttpResponse.json(fullEvent)
|
||||
}),
|
||||
)
|
||||
|
||||
await page.goto(`/events/${fullEvent.eventToken}`)
|
||||
await page.getByRole('button', { name: "I'm attending" }).click()
|
||||
|
||||
const dialog = page.getByRole('dialog', { name: 'RSVP' })
|
||||
await dialog.getByRole('button', { name: 'Count me in' }).click()
|
||||
|
||||
await expect(page.getByText('Please enter your name.')).toBeVisible()
|
||||
})
|
||||
|
||||
test('restores RSVP status from localStorage on page load', async ({ page, network }) => {
|
||||
network.use(
|
||||
http.get('*/api/events/:token', () => {
|
||||
return HttpResponse.json(fullEvent)
|
||||
}),
|
||||
)
|
||||
|
||||
// Pre-seed localStorage
|
||||
await page.goto('/')
|
||||
await page.evaluate(() => {
|
||||
localStorage.setItem(
|
||||
'fete:events',
|
||||
JSON.stringify([
|
||||
{
|
||||
eventToken: 'a1b2c3d4-e5f6-7890-abcd-ef1234567890',
|
||||
title: 'Summer BBQ',
|
||||
dateTime: '2026-03-15T20:00:00+01:00',
|
||||
expiryDate: '',
|
||||
rsvpToken: 'existing-rsvp-token',
|
||||
rsvpName: 'Anna',
|
||||
},
|
||||
]),
|
||||
)
|
||||
})
|
||||
|
||||
await page.goto(`/events/${fullEvent.eventToken}`)
|
||||
|
||||
// Status bar should show, not CTA
|
||||
await expect(page.getByText("You're attending!")).toBeVisible()
|
||||
await expect(page.getByRole('button', { name: "I'm attending" })).not.toBeVisible()
|
||||
})
|
||||
|
||||
test('shows error when server is unreachable during RSVP', async ({ page, network }) => {
|
||||
network.use(
|
||||
http.get('*/api/events/:token', () => {
|
||||
return HttpResponse.json(fullEvent)
|
||||
}),
|
||||
http.post('*/api/events/:token/rsvps', () => {
|
||||
return HttpResponse.json(
|
||||
{ type: 'about:blank', title: 'Bad Request', status: 400 },
|
||||
{ status: 400, headers: { 'Content-Type': 'application/problem+json' } },
|
||||
)
|
||||
}),
|
||||
)
|
||||
|
||||
await page.goto(`/events/${fullEvent.eventToken}`)
|
||||
await page.getByRole('button', { name: "I'm attending" }).click()
|
||||
|
||||
const dialog = page.getByRole('dialog', { name: 'RSVP' })
|
||||
await dialog.getByLabel('Your name').fill('Max')
|
||||
await dialog.getByRole('button', { name: 'Count me in' }).click()
|
||||
|
||||
await expect(page.getByText('Could not submit RSVP. Please try again.')).toBeVisible()
|
||||
})
|
||||
|
||||
test('does not show RSVP bar for organizer', async ({ page, network }) => {
|
||||
network.use(
|
||||
http.get('*/api/events/:token', () => {
|
||||
return HttpResponse.json(fullEvent)
|
||||
}),
|
||||
)
|
||||
|
||||
// Pre-seed localStorage with organizer token
|
||||
await page.goto('/')
|
||||
await page.evaluate(() => {
|
||||
localStorage.setItem(
|
||||
'fete:events',
|
||||
JSON.stringify([
|
||||
{
|
||||
eventToken: 'a1b2c3d4-e5f6-7890-abcd-ef1234567890',
|
||||
organizerToken: 'org-token-123',
|
||||
title: 'Summer BBQ',
|
||||
dateTime: '2026-03-15T20:00:00+01:00',
|
||||
expiryDate: '',
|
||||
},
|
||||
]),
|
||||
)
|
||||
})
|
||||
|
||||
await page.goto(`/events/${fullEvent.eventToken}`)
|
||||
|
||||
// Event content should load
|
||||
await expect(page.getByText('Summer BBQ')).toBeVisible()
|
||||
|
||||
// But no RSVP bar
|
||||
await expect(page.getByRole('button', { name: "I'm attending" })).not.toBeVisible()
|
||||
await expect(page.getByText("You're attending!")).not.toBeVisible()
|
||||
})
|
||||
|
||||
test('does not show RSVP bar on expired event', async ({ page, network }) => {
|
||||
network.use(
|
||||
http.get('*/api/events/:token', () => {
|
||||
return HttpResponse.json({ ...fullEvent, expired: true })
|
||||
}),
|
||||
)
|
||||
|
||||
await page.goto(`/events/${fullEvent.eventToken}`)
|
||||
|
||||
await expect(page.getByText('This event has ended.')).toBeVisible()
|
||||
await expect(page.getByRole('button', { name: "I'm attending" })).not.toBeVisible()
|
||||
})
|
||||
})
|
||||
377
frontend/e2e/home-events.spec.ts
Normal file
377
frontend/e2e/home-events.spec.ts
Normal file
@@ -0,0 +1,377 @@
|
||||
import { test, expect } from './msw-setup'
|
||||
import type { StoredEvent } from '../src/composables/useEventStorage'
|
||||
|
||||
const STORAGE_KEY = 'fete:events'
|
||||
|
||||
const futureEvent1: StoredEvent = {
|
||||
eventToken: 'future-aaa',
|
||||
title: 'Summer BBQ',
|
||||
dateTime: '2027-06-15T18:00:00Z',
|
||||
expiryDate: '2027-06-16T00:00:00Z',
|
||||
organizerToken: 'org-token-1',
|
||||
}
|
||||
|
||||
const futureEvent2: StoredEvent = {
|
||||
eventToken: 'future-bbb',
|
||||
title: 'Team Meeting',
|
||||
dateTime: '2027-01-10T09:00:00Z',
|
||||
expiryDate: '2027-01-11T00:00:00Z',
|
||||
rsvpToken: 'rsvp-token-1',
|
||||
rsvpName: 'Alice',
|
||||
}
|
||||
|
||||
const pastEvent: StoredEvent = {
|
||||
eventToken: 'past-ccc',
|
||||
title: 'New Year Party',
|
||||
dateTime: '2025-01-01T00:00:00Z',
|
||||
expiryDate: '2025-01-02T00:00:00Z',
|
||||
}
|
||||
|
||||
function seedEvents(events: StoredEvent[]): string {
|
||||
return `window.localStorage.setItem('${STORAGE_KEY}', ${JSON.stringify(JSON.stringify(events))})`
|
||||
}
|
||||
|
||||
test.describe('US2: Empty State', () => {
|
||||
test('shows empty state when no events are stored', async ({ page }) => {
|
||||
await page.goto('/')
|
||||
|
||||
await expect(page.getByText('No events yet')).toBeVisible()
|
||||
await expect(page.getByRole('link', { name: /Create Event/ })).toBeVisible()
|
||||
})
|
||||
|
||||
test('empty state links to create page', async ({ page }) => {
|
||||
await page.goto('/')
|
||||
|
||||
const link = page.getByRole('link', { name: /Create Event/ })
|
||||
await expect(link).toHaveAttribute('href', '/create')
|
||||
})
|
||||
|
||||
test('empty state is hidden when events exist', async ({ page }) => {
|
||||
await page.addInitScript(seedEvents([futureEvent1]))
|
||||
await page.goto('/')
|
||||
|
||||
await expect(page.getByText('No events yet')).not.toBeVisible()
|
||||
})
|
||||
})
|
||||
|
||||
test.describe('US4: Past Events Appear Faded', () => {
|
||||
test('past events have the faded modifier class', async ({ page }) => {
|
||||
await page.addInitScript(seedEvents([futureEvent1, pastEvent]))
|
||||
await page.goto('/')
|
||||
|
||||
const cards = page.locator('.event-card')
|
||||
await expect(cards).toHaveCount(2)
|
||||
|
||||
// Future event should NOT have past class
|
||||
const futureCard = cards.filter({ hasText: 'Summer BBQ' })
|
||||
await expect(futureCard).not.toHaveClass(/event-card--past/)
|
||||
|
||||
// Past event should have past class
|
||||
const pastCard = cards.filter({ hasText: 'New Year Party' })
|
||||
await expect(pastCard).toHaveClass(/event-card--past/)
|
||||
})
|
||||
|
||||
test('past events remain clickable', async ({ page, network }) => {
|
||||
await page.addInitScript(seedEvents([pastEvent]))
|
||||
|
||||
const { http, HttpResponse } = await import('msw')
|
||||
network.use(
|
||||
http.get('*/api/events/:token', () => {
|
||||
return HttpResponse.json({
|
||||
eventToken: pastEvent.eventToken,
|
||||
title: pastEvent.title,
|
||||
dateTime: pastEvent.dateTime,
|
||||
description: '',
|
||||
location: '',
|
||||
timezone: 'UTC',
|
||||
attendeeCount: 0,
|
||||
expired: true,
|
||||
})
|
||||
}),
|
||||
)
|
||||
|
||||
await page.goto('/')
|
||||
await page.getByText('New Year Party').click()
|
||||
await expect(page).toHaveURL(`/events/${pastEvent.eventToken}`)
|
||||
})
|
||||
})
|
||||
|
||||
test.describe('US3: Remove Event from List', () => {
|
||||
test('delete icon triggers confirmation dialog, confirm removes event', async ({ page }) => {
|
||||
await page.addInitScript(seedEvents([futureEvent1, futureEvent2]))
|
||||
await page.goto('/')
|
||||
|
||||
// Both events visible
|
||||
await expect(page.getByText('Summer BBQ')).toBeVisible()
|
||||
await expect(page.getByText('Team Meeting')).toBeVisible()
|
||||
|
||||
// Click delete on Summer BBQ
|
||||
await page.getByRole('button', { name: /Remove Summer BBQ/ }).click()
|
||||
|
||||
// Confirmation dialog appears
|
||||
await expect(page.getByText('Remove event?')).toBeVisible()
|
||||
|
||||
// Confirm removal
|
||||
await page.getByRole('button', { name: 'Remove', exact: true }).click()
|
||||
|
||||
// Event is gone, other remains
|
||||
await expect(page.getByText('Summer BBQ')).not.toBeVisible()
|
||||
await expect(page.getByText('Team Meeting')).toBeVisible()
|
||||
})
|
||||
|
||||
test('cancel keeps the event in the list', async ({ page }) => {
|
||||
await page.addInitScript(seedEvents([futureEvent1]))
|
||||
await page.goto('/')
|
||||
|
||||
await page.getByRole('button', { name: /Remove Summer BBQ/ }).click()
|
||||
await expect(page.getByText('Remove event?')).toBeVisible()
|
||||
|
||||
// Cancel
|
||||
await page.getByRole('button', { name: 'Cancel' }).click()
|
||||
|
||||
// Dialog gone, event still there
|
||||
await expect(page.getByText('Remove event?')).not.toBeVisible()
|
||||
await expect(page.getByText('Summer BBQ')).toBeVisible()
|
||||
})
|
||||
})
|
||||
|
||||
test.describe('US5: Visual Distinction for Event Roles', () => {
|
||||
test('shows organizer badge for events with organizerToken', async ({ page }) => {
|
||||
await page.addInitScript(seedEvents([futureEvent1]))
|
||||
await page.goto('/')
|
||||
|
||||
const card = page.locator('.event-card').filter({ hasText: 'Summer BBQ' })
|
||||
const badge = card.locator('.event-card__badge')
|
||||
await expect(badge).toBeVisible()
|
||||
await expect(badge).toHaveText('Organizer')
|
||||
await expect(badge).toHaveClass(/event-card__badge--organizer/)
|
||||
})
|
||||
|
||||
test('shows attendee badge for events with rsvpToken only', async ({ page }) => {
|
||||
await page.addInitScript(seedEvents([futureEvent2]))
|
||||
await page.goto('/')
|
||||
|
||||
const card = page.locator('.event-card').filter({ hasText: 'Team Meeting' })
|
||||
const badge = card.locator('.event-card__badge')
|
||||
await expect(badge).toBeVisible()
|
||||
await expect(badge).toHaveText('Attendee')
|
||||
await expect(badge).toHaveClass(/event-card__badge--attendee/)
|
||||
})
|
||||
|
||||
test('shows no badge for events without organizerToken or rsvpToken', async ({ page }) => {
|
||||
await page.addInitScript(seedEvents([pastEvent]))
|
||||
await page.goto('/')
|
||||
|
||||
const card = page.locator('.event-card').filter({ hasText: 'New Year Party' })
|
||||
await expect(card.locator('.event-card__badge')).toHaveCount(0)
|
||||
})
|
||||
})
|
||||
|
||||
test.describe('FAB: Create Event Button', () => {
|
||||
test('FAB is visible when events exist', async ({ page }) => {
|
||||
await page.addInitScript(seedEvents([futureEvent1]))
|
||||
await page.goto('/')
|
||||
|
||||
const fab = page.getByRole('link', { name: 'Create event' })
|
||||
await expect(fab).toBeVisible()
|
||||
})
|
||||
|
||||
test('FAB navigates to create page', async ({ page }) => {
|
||||
await page.addInitScript(seedEvents([futureEvent1]))
|
||||
await page.goto('/')
|
||||
|
||||
const fab = page.getByRole('link', { name: 'Create event' })
|
||||
await expect(fab).toHaveAttribute('href', '/create')
|
||||
})
|
||||
|
||||
test('FAB is not visible on empty state (empty state has its own CTA)', async ({ page }) => {
|
||||
await page.goto('/')
|
||||
|
||||
await expect(page.locator('.fab')).toHaveCount(0)
|
||||
})
|
||||
})
|
||||
|
||||
test.describe('Temporal Grouping: Section Headers', () => {
|
||||
test('events are distributed under correct section headers', async ({ page }) => {
|
||||
// Use dates relative to "now" to ensure correct section assignment
|
||||
const now = new Date()
|
||||
const todayEvent: StoredEvent = {
|
||||
eventToken: 'today-1',
|
||||
title: 'Today Standup',
|
||||
dateTime: new Date(now.getFullYear(), now.getMonth(), now.getDate(), 18, 0, 0).toISOString(),
|
||||
expiryDate: '',
|
||||
}
|
||||
const laterEvent: StoredEvent = {
|
||||
eventToken: 'later-1',
|
||||
title: 'Future Conference',
|
||||
dateTime: new Date(now.getFullYear() + 1, 0, 15, 10, 0, 0).toISOString(),
|
||||
expiryDate: '',
|
||||
}
|
||||
await page.addInitScript(seedEvents([todayEvent, laterEvent, pastEvent]))
|
||||
await page.goto('/')
|
||||
|
||||
// Verify section headers appear
|
||||
await expect(page.getByRole('heading', { name: 'Today', level: 2 })).toBeVisible()
|
||||
await expect(page.getByRole('heading', { name: 'Later', level: 2 })).toBeVisible()
|
||||
await expect(page.getByRole('heading', { name: 'Past', level: 2 })).toBeVisible()
|
||||
|
||||
// Events are in the correct sections
|
||||
const sections = page.locator('.event-section')
|
||||
const todaySection = sections.filter({ has: page.getByRole('heading', { name: 'Today', level: 2 }) })
|
||||
await expect(todaySection.getByText('Today Standup')).toBeVisible()
|
||||
|
||||
const laterSection = sections.filter({ has: page.getByRole('heading', { name: 'Later', level: 2 }) })
|
||||
await expect(laterSection.getByText('Future Conference')).toBeVisible()
|
||||
|
||||
const pastSection = sections.filter({ has: page.getByRole('heading', { name: 'Past', level: 2 }) })
|
||||
await expect(pastSection.getByText('New Year Party')).toBeVisible()
|
||||
})
|
||||
|
||||
test('empty sections are not rendered', async ({ page }) => {
|
||||
// Only a past event — no Today, This Week, or Later sections
|
||||
await page.addInitScript(seedEvents([pastEvent]))
|
||||
await page.goto('/')
|
||||
|
||||
await expect(page.getByRole('heading', { name: 'Past', level: 2 })).toBeVisible()
|
||||
await expect(page.getByRole('heading', { name: 'Today', level: 2 })).toHaveCount(0)
|
||||
await expect(page.getByRole('heading', { name: 'This Week', level: 2 })).toHaveCount(0)
|
||||
await expect(page.getByRole('heading', { name: 'Next Week', level: 2 })).toHaveCount(0)
|
||||
await expect(page.getByRole('heading', { name: 'Later', level: 2 })).toHaveCount(0)
|
||||
})
|
||||
|
||||
test('Today section header has emphasis CSS class', async ({ page }) => {
|
||||
const now = new Date()
|
||||
const todayEvent: StoredEvent = {
|
||||
eventToken: 'today-emph',
|
||||
title: 'Emphasis Test',
|
||||
dateTime: new Date(now.getFullYear(), now.getMonth(), now.getDate(), 20, 0, 0).toISOString(),
|
||||
expiryDate: '',
|
||||
}
|
||||
await page.addInitScript(seedEvents([todayEvent]))
|
||||
await page.goto('/')
|
||||
|
||||
const todayHeader = page.getByRole('heading', { name: 'Today', level: 2 })
|
||||
await expect(todayHeader).toHaveClass(/section-header--emphasized/)
|
||||
})
|
||||
})
|
||||
|
||||
test.describe('Temporal Grouping: Date Subheaders', () => {
|
||||
test('no date subheader in Today section', async ({ page }) => {
|
||||
const now = new Date()
|
||||
const todayEvent: StoredEvent = {
|
||||
eventToken: 'today-sub',
|
||||
title: 'No Subheader Test',
|
||||
dateTime: new Date(now.getFullYear(), now.getMonth(), now.getDate(), 19, 0, 0).toISOString(),
|
||||
expiryDate: '',
|
||||
}
|
||||
await page.addInitScript(seedEvents([todayEvent]))
|
||||
await page.goto('/')
|
||||
|
||||
const todaySection = page.locator('.event-section').filter({
|
||||
has: page.getByRole('heading', { name: 'Today', level: 2 }),
|
||||
})
|
||||
await expect(todaySection.locator('.date-subheader')).toHaveCount(0)
|
||||
})
|
||||
|
||||
test('date subheaders appear in Later section', async ({ page }) => {
|
||||
await page.addInitScript(seedEvents([futureEvent1, futureEvent2]))
|
||||
await page.goto('/')
|
||||
|
||||
const laterSection = page.locator('.event-section').filter({
|
||||
has: page.getByRole('heading', { name: 'Later', level: 2 }),
|
||||
})
|
||||
// Both future events are on different dates, so expect subheaders
|
||||
const subheaders = laterSection.locator('.date-subheader')
|
||||
await expect(subheaders).toHaveCount(2)
|
||||
})
|
||||
|
||||
test('date subheaders appear in Past section', async ({ page }) => {
|
||||
await page.addInitScript(seedEvents([pastEvent]))
|
||||
await page.goto('/')
|
||||
|
||||
const pastSection = page.locator('.event-section').filter({
|
||||
has: page.getByRole('heading', { name: 'Past', level: 2 }),
|
||||
})
|
||||
await expect(pastSection.locator('.date-subheader')).toHaveCount(1)
|
||||
})
|
||||
})
|
||||
|
||||
test.describe('Temporal Grouping: Time Display', () => {
|
||||
test('future event cards show clock time', async ({ page }) => {
|
||||
await page.addInitScript(seedEvents([futureEvent1]))
|
||||
await page.goto('/')
|
||||
|
||||
const timeLabel = page.locator('.event-card__time')
|
||||
const text = await timeLabel.first().textContent()
|
||||
// Should show clock time (e.g., "18:00" or "6:00 PM"), not relative time
|
||||
expect(text).toMatch(/\d{1,2}[:.]\d{2}/)
|
||||
})
|
||||
|
||||
test('past event cards show relative time', async ({ page }) => {
|
||||
await page.addInitScript(seedEvents([pastEvent]))
|
||||
await page.goto('/')
|
||||
|
||||
const timeLabel = page.locator('.event-card__time')
|
||||
const text = await timeLabel.first().textContent()
|
||||
// Should show relative time like "X years ago" or "last year"
|
||||
expect(text).toMatch(/ago|last|yesterday/)
|
||||
})
|
||||
})
|
||||
|
||||
test.describe('US1: View My Events', () => {
|
||||
test('displays all stored events with title and relative time', async ({ page }) => {
|
||||
await page.addInitScript(seedEvents([futureEvent1, futureEvent2, pastEvent]))
|
||||
await page.goto('/')
|
||||
|
||||
await expect(page.getByText('Summer BBQ')).toBeVisible()
|
||||
await expect(page.getByText('Team Meeting')).toBeVisible()
|
||||
await expect(page.getByText('New Year Party')).toBeVisible()
|
||||
})
|
||||
|
||||
test('events are sorted: upcoming ascending, then past', async ({ page }) => {
|
||||
await page.addInitScript(seedEvents([futureEvent1, futureEvent2, pastEvent]))
|
||||
await page.goto('/')
|
||||
|
||||
const titles = page.locator('.event-card__title')
|
||||
await expect(titles).toHaveCount(3)
|
||||
// Team Meeting (Jan 2027) before Summer BBQ (Jun 2027), then past event
|
||||
await expect(titles.nth(0)).toHaveText('Team Meeting')
|
||||
await expect(titles.nth(1)).toHaveText('Summer BBQ')
|
||||
await expect(titles.nth(2)).toHaveText('New Year Party')
|
||||
})
|
||||
|
||||
test('clicking an event navigates to its detail page', async ({ page, network }) => {
|
||||
await page.addInitScript(seedEvents([futureEvent1]))
|
||||
|
||||
// Mock the event detail API so navigation doesn't fail
|
||||
const { http, HttpResponse } = await import('msw')
|
||||
network.use(
|
||||
http.get('*/api/events/:token', () => {
|
||||
return HttpResponse.json({
|
||||
eventToken: futureEvent1.eventToken,
|
||||
title: futureEvent1.title,
|
||||
dateTime: futureEvent1.dateTime,
|
||||
description: '',
|
||||
location: '',
|
||||
timezone: 'UTC',
|
||||
attendeeCount: 0,
|
||||
expired: false,
|
||||
})
|
||||
}),
|
||||
)
|
||||
|
||||
await page.goto('/')
|
||||
await page.getByText('Summer BBQ').click()
|
||||
await expect(page).toHaveURL(`/events/${futureEvent1.eventToken}`)
|
||||
})
|
||||
|
||||
test('each event shows a relative time label', async ({ page }) => {
|
||||
await page.addInitScript(seedEvents([futureEvent1]))
|
||||
await page.goto('/')
|
||||
|
||||
// The relative time element should exist and contain text (exact value depends on current time)
|
||||
const timeLabel = page.locator('.event-card__time')
|
||||
await expect(timeLabel).toHaveCount(1)
|
||||
await expect(timeLabel.first()).not.toBeEmpty()
|
||||
})
|
||||
})
|
||||
52
frontend/package-lock.json
generated
52
frontend/package-lock.json
generated
@@ -1201,15 +1201,15 @@
|
||||
}
|
||||
},
|
||||
"node_modules/@eslint/config-array": {
|
||||
"version": "0.23.2",
|
||||
"resolved": "https://registry.npmjs.org/@eslint/config-array/-/config-array-0.23.2.tgz",
|
||||
"integrity": "sha512-YF+fE6LV4v5MGWRGj7G404/OZzGNepVF8fxk7jqmqo3lrza7a0uUcDnROGRBG1WFC1omYUS/Wp1f42i0M+3Q3A==",
|
||||
"version": "0.23.3",
|
||||
"resolved": "https://registry.npmjs.org/@eslint/config-array/-/config-array-0.23.3.tgz",
|
||||
"integrity": "sha512-j+eEWmB6YYLwcNOdlwQ6L2OsptI/LO6lNBuLIqe5R7RetD658HLoF+Mn7LzYmAWWNNzdC6cqP+L6r8ujeYXWLw==",
|
||||
"dev": true,
|
||||
"license": "Apache-2.0",
|
||||
"dependencies": {
|
||||
"@eslint/object-schema": "^3.0.2",
|
||||
"@eslint/object-schema": "^3.0.3",
|
||||
"debug": "^4.3.1",
|
||||
"minimatch": "^10.2.1"
|
||||
"minimatch": "^10.2.4"
|
||||
},
|
||||
"engines": {
|
||||
"node": "^20.19.0 || ^22.13.0 || >=24"
|
||||
@@ -1229,9 +1229,9 @@
|
||||
}
|
||||
},
|
||||
"node_modules/@eslint/core": {
|
||||
"version": "1.1.0",
|
||||
"resolved": "https://registry.npmjs.org/@eslint/core/-/core-1.1.0.tgz",
|
||||
"integrity": "sha512-/nr9K9wkr3P1EzFTdFdMoLuo1PmIxjmwvPozwoSodjNBdefGujXQUF93u1DDZpEaTuDvMsIQddsd35BwtrW9Xw==",
|
||||
"version": "1.1.1",
|
||||
"resolved": "https://registry.npmjs.org/@eslint/core/-/core-1.1.1.tgz",
|
||||
"integrity": "sha512-QUPblTtE51/7/Zhfv8BDwO0qkkzQL7P/aWWbqcf4xWLEYn1oKjdO0gglQBB4GAsu7u6wjijbCmzsUTy6mnk6oQ==",
|
||||
"dev": true,
|
||||
"license": "Apache-2.0",
|
||||
"dependencies": {
|
||||
@@ -1242,9 +1242,9 @@
|
||||
}
|
||||
},
|
||||
"node_modules/@eslint/object-schema": {
|
||||
"version": "3.0.2",
|
||||
"resolved": "https://registry.npmjs.org/@eslint/object-schema/-/object-schema-3.0.2.tgz",
|
||||
"integrity": "sha512-HOy56KJt48Bx8KmJ+XGQNSUMT/6dZee/M54XyUyuvTvPXJmsERRvBchsUVx1UMe1WwIH49XLAczNC7V2INsuUw==",
|
||||
"version": "3.0.3",
|
||||
"resolved": "https://registry.npmjs.org/@eslint/object-schema/-/object-schema-3.0.3.tgz",
|
||||
"integrity": "sha512-iM869Pugn9Nsxbh/YHRqYiqd23AmIbxJOcpUMOuWCVNdoQJ5ZtwL6h3t0bcZzJUlC3Dq9jCFCESBZnX0GTv7iQ==",
|
||||
"dev": true,
|
||||
"license": "Apache-2.0",
|
||||
"engines": {
|
||||
@@ -1252,13 +1252,13 @@
|
||||
}
|
||||
},
|
||||
"node_modules/@eslint/plugin-kit": {
|
||||
"version": "0.6.0",
|
||||
"resolved": "https://registry.npmjs.org/@eslint/plugin-kit/-/plugin-kit-0.6.0.tgz",
|
||||
"integrity": "sha512-bIZEUzOI1jkhviX2cp5vNyXQc6olzb2ohewQubuYlMXZ2Q/XjBO0x0XhGPvc9fjSIiUN0vw+0hq53BJ4eQSJKQ==",
|
||||
"version": "0.6.1",
|
||||
"resolved": "https://registry.npmjs.org/@eslint/plugin-kit/-/plugin-kit-0.6.1.tgz",
|
||||
"integrity": "sha512-iH1B076HoAshH1mLpHMgwdGeTs0CYwL0SPMkGuSebZrwBp16v415e9NZXg2jtrqPVQjf6IANe2Vtlr5KswtcZQ==",
|
||||
"dev": true,
|
||||
"license": "Apache-2.0",
|
||||
"dependencies": {
|
||||
"@eslint/core": "^1.1.0",
|
||||
"@eslint/core": "^1.1.1",
|
||||
"levn": "^0.4.1"
|
||||
},
|
||||
"engines": {
|
||||
@@ -4304,18 +4304,18 @@
|
||||
}
|
||||
},
|
||||
"node_modules/eslint": {
|
||||
"version": "10.0.2",
|
||||
"resolved": "https://registry.npmjs.org/eslint/-/eslint-10.0.2.tgz",
|
||||
"integrity": "sha512-uYixubwmqJZH+KLVYIVKY1JQt7tysXhtj21WSvjcSmU5SVNzMus1bgLe+pAt816yQ8opKfheVVoPLqvVMGejYw==",
|
||||
"version": "10.0.3",
|
||||
"resolved": "https://registry.npmjs.org/eslint/-/eslint-10.0.3.tgz",
|
||||
"integrity": "sha512-COV33RzXZkqhG9P2rZCFl9ZmJ7WL+gQSCRzE7RhkbclbQPtLAWReL7ysA0Sh4c8Im2U9ynybdR56PV0XcKvqaQ==",
|
||||
"dev": true,
|
||||
"license": "MIT",
|
||||
"dependencies": {
|
||||
"@eslint-community/eslint-utils": "^4.8.0",
|
||||
"@eslint-community/regexpp": "^4.12.2",
|
||||
"@eslint/config-array": "^0.23.2",
|
||||
"@eslint/config-array": "^0.23.3",
|
||||
"@eslint/config-helpers": "^0.5.2",
|
||||
"@eslint/core": "^1.1.0",
|
||||
"@eslint/plugin-kit": "^0.6.0",
|
||||
"@eslint/core": "^1.1.1",
|
||||
"@eslint/plugin-kit": "^0.6.1",
|
||||
"@humanfs/node": "^0.16.6",
|
||||
"@humanwhocodes/module-importer": "^1.0.1",
|
||||
"@humanwhocodes/retry": "^0.4.2",
|
||||
@@ -4324,7 +4324,7 @@
|
||||
"cross-spawn": "^7.0.6",
|
||||
"debug": "^4.3.2",
|
||||
"escape-string-regexp": "^4.0.0",
|
||||
"eslint-scope": "^9.1.1",
|
||||
"eslint-scope": "^9.1.2",
|
||||
"eslint-visitor-keys": "^5.0.1",
|
||||
"espree": "^11.1.1",
|
||||
"esquery": "^1.7.0",
|
||||
@@ -4337,7 +4337,7 @@
|
||||
"imurmurhash": "^0.1.4",
|
||||
"is-glob": "^4.0.0",
|
||||
"json-stable-stringify-without-jsonify": "^1.0.1",
|
||||
"minimatch": "^10.2.1",
|
||||
"minimatch": "^10.2.4",
|
||||
"natural-compare": "^1.4.0",
|
||||
"optionator": "^0.9.3"
|
||||
},
|
||||
@@ -4418,9 +4418,9 @@
|
||||
}
|
||||
},
|
||||
"node_modules/eslint-scope": {
|
||||
"version": "9.1.1",
|
||||
"resolved": "https://registry.npmjs.org/eslint-scope/-/eslint-scope-9.1.1.tgz",
|
||||
"integrity": "sha512-GaUN0sWim5qc8KVErfPBWmc31LEsOkrUJbvJZV+xuL3u2phMUK4HIvXlWAakfC8W4nzlK+chPEAkYOYb5ZScIw==",
|
||||
"version": "9.1.2",
|
||||
"resolved": "https://registry.npmjs.org/eslint-scope/-/eslint-scope-9.1.2.tgz",
|
||||
"integrity": "sha512-xS90H51cKw0jltxmvmHy2Iai1LIqrfbw57b79w/J7MfvDfkIkFZ+kj6zC3BjtUwh150HsSSdxXZcsuv72miDFQ==",
|
||||
"dev": true,
|
||||
"license": "BSD-2-Clause",
|
||||
"dependencies": {
|
||||
|
||||
BIN
frontend/src/assets/images/event-hero-placeholder.jpg
Normal file
BIN
frontend/src/assets/images/event-hero-placeholder.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 101 KiB |
@@ -192,3 +192,34 @@ textarea.form-field {
|
||||
white-space: nowrap;
|
||||
border: 0;
|
||||
}
|
||||
|
||||
/* Bottom sheet form */
|
||||
.sheet-title {
|
||||
font-size: 1.2rem;
|
||||
font-weight: 700;
|
||||
color: var(--color-text);
|
||||
}
|
||||
|
||||
.rsvp-form {
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: var(--spacing-md);
|
||||
}
|
||||
|
||||
.rsvp-form__label {
|
||||
font-size: 0.85rem;
|
||||
font-weight: 700;
|
||||
color: var(--color-text);
|
||||
padding-left: 0.25rem;
|
||||
}
|
||||
|
||||
.rsvp-form__field-error {
|
||||
color: #d32f2f;
|
||||
font-size: 0.875rem;
|
||||
font-weight: 600;
|
||||
padding-left: 0.25rem;
|
||||
}
|
||||
|
||||
.rsvp-form__error {
|
||||
text-align: center;
|
||||
}
|
||||
|
||||
96
frontend/src/components/BottomSheet.vue
Normal file
96
frontend/src/components/BottomSheet.vue
Normal file
@@ -0,0 +1,96 @@
|
||||
<template>
|
||||
<Teleport to="body">
|
||||
<Transition name="sheet">
|
||||
<div v-if="open" class="sheet-backdrop" @click.self="$emit('close')" @keydown.escape="$emit('close')">
|
||||
<div class="sheet" role="dialog" aria-modal="true" :aria-label="label" ref="sheetEl" tabindex="-1">
|
||||
<div class="sheet__handle" aria-hidden="true" />
|
||||
<slot />
|
||||
</div>
|
||||
</div>
|
||||
</Transition>
|
||||
</Teleport>
|
||||
</template>
|
||||
|
||||
<script setup lang="ts">
|
||||
import { ref, watch, nextTick } from 'vue'
|
||||
|
||||
defineProps<{
|
||||
open: boolean
|
||||
label: string
|
||||
}>()
|
||||
|
||||
defineEmits<{
|
||||
close: []
|
||||
}>()
|
||||
|
||||
const sheetEl = ref<HTMLElement | null>(null)
|
||||
|
||||
watch(
|
||||
() => sheetEl.value,
|
||||
async (el) => {
|
||||
if (el) {
|
||||
await nextTick()
|
||||
const firstInput = el.querySelector<HTMLElement>('input, textarea, button[type="submit"]')
|
||||
if (firstInput) {
|
||||
firstInput.focus()
|
||||
} else {
|
||||
el.focus()
|
||||
}
|
||||
}
|
||||
},
|
||||
)
|
||||
</script>
|
||||
|
||||
<style scoped>
|
||||
.sheet-backdrop {
|
||||
position: fixed;
|
||||
inset: 0;
|
||||
background: rgba(0, 0, 0, 0.4);
|
||||
display: flex;
|
||||
align-items: flex-end;
|
||||
justify-content: center;
|
||||
z-index: 100;
|
||||
}
|
||||
|
||||
.sheet {
|
||||
background: var(--color-card);
|
||||
border-radius: 20px 20px 0 0;
|
||||
padding: var(--spacing-lg) var(--spacing-xl) var(--spacing-2xl);
|
||||
width: 100%;
|
||||
max-width: var(--content-max-width);
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: var(--spacing-lg);
|
||||
outline: none;
|
||||
}
|
||||
|
||||
.sheet__handle {
|
||||
width: 36px;
|
||||
height: 4px;
|
||||
background: #ccc;
|
||||
border-radius: 2px;
|
||||
align-self: center;
|
||||
flex-shrink: 0;
|
||||
}
|
||||
|
||||
/* Transition */
|
||||
.sheet-enter-active,
|
||||
.sheet-leave-active {
|
||||
transition: opacity 0.25s ease;
|
||||
}
|
||||
|
||||
.sheet-enter-active .sheet,
|
||||
.sheet-leave-active .sheet {
|
||||
transition: transform 0.25s ease;
|
||||
}
|
||||
|
||||
.sheet-enter-from,
|
||||
.sheet-leave-to {
|
||||
opacity: 0;
|
||||
}
|
||||
|
||||
.sheet-enter-from .sheet,
|
||||
.sheet-leave-to .sheet {
|
||||
transform: translateY(100%);
|
||||
}
|
||||
</style>
|
||||
151
frontend/src/components/ConfirmDialog.vue
Normal file
151
frontend/src/components/ConfirmDialog.vue
Normal file
@@ -0,0 +1,151 @@
|
||||
<template>
|
||||
<Teleport to="body">
|
||||
<Transition name="confirm-dialog">
|
||||
<div v-if="open" class="confirm-dialog__overlay" @click.self="$emit('cancel')">
|
||||
<div
|
||||
class="confirm-dialog"
|
||||
role="alertdialog"
|
||||
aria-modal="true"
|
||||
:aria-label="title"
|
||||
@keydown.escape="$emit('cancel')"
|
||||
>
|
||||
<p class="confirm-dialog__title">{{ title }}</p>
|
||||
<p class="confirm-dialog__message">{{ message }}</p>
|
||||
<div class="confirm-dialog__actions">
|
||||
<button
|
||||
ref="cancelBtn"
|
||||
class="confirm-dialog__btn confirm-dialog__btn--cancel"
|
||||
type="button"
|
||||
@click="$emit('cancel')"
|
||||
>
|
||||
{{ cancelLabel }}
|
||||
</button>
|
||||
<button
|
||||
class="confirm-dialog__btn confirm-dialog__btn--confirm"
|
||||
type="button"
|
||||
@click="$emit('confirm')"
|
||||
>
|
||||
{{ confirmLabel }}
|
||||
</button>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</Transition>
|
||||
</Teleport>
|
||||
</template>
|
||||
|
||||
<script setup lang="ts">
|
||||
import { ref, watch, nextTick } from 'vue'
|
||||
|
||||
const props = withDefaults(
|
||||
defineProps<{
|
||||
open: boolean
|
||||
title?: string
|
||||
message?: string
|
||||
confirmLabel?: string
|
||||
cancelLabel?: string
|
||||
}>(),
|
||||
{
|
||||
title: 'Are you sure?',
|
||||
message: '',
|
||||
confirmLabel: 'Remove',
|
||||
cancelLabel: 'Cancel',
|
||||
},
|
||||
)
|
||||
|
||||
defineEmits<{
|
||||
confirm: []
|
||||
cancel: []
|
||||
}>()
|
||||
|
||||
const cancelBtn = ref<HTMLButtonElement | null>(null)
|
||||
|
||||
watch(
|
||||
() => props.open,
|
||||
async (isOpen) => {
|
||||
if (isOpen) {
|
||||
await nextTick()
|
||||
cancelBtn.value?.focus()
|
||||
}
|
||||
},
|
||||
)
|
||||
</script>
|
||||
|
||||
<style scoped>
|
||||
.confirm-dialog__overlay {
|
||||
position: fixed;
|
||||
inset: 0;
|
||||
background: rgba(0, 0, 0, 0.4);
|
||||
display: flex;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
z-index: 1000;
|
||||
padding: var(--spacing-lg);
|
||||
}
|
||||
|
||||
.confirm-dialog {
|
||||
background: var(--color-card);
|
||||
border-radius: var(--radius-card);
|
||||
box-shadow: 0 8px 32px rgba(0, 0, 0, 0.2);
|
||||
padding: var(--spacing-xl);
|
||||
max-width: 320px;
|
||||
width: 100%;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: var(--spacing-md);
|
||||
}
|
||||
|
||||
.confirm-dialog__title {
|
||||
font-size: 1.05rem;
|
||||
font-weight: 700;
|
||||
color: var(--color-text);
|
||||
}
|
||||
|
||||
.confirm-dialog__message {
|
||||
font-size: 0.9rem;
|
||||
font-weight: 400;
|
||||
color: #666;
|
||||
}
|
||||
|
||||
.confirm-dialog__actions {
|
||||
display: flex;
|
||||
gap: var(--spacing-sm);
|
||||
justify-content: flex-end;
|
||||
margin-top: var(--spacing-xs);
|
||||
}
|
||||
|
||||
.confirm-dialog__btn {
|
||||
padding: 0.5rem 1rem;
|
||||
border: none;
|
||||
border-radius: var(--radius-button);
|
||||
font-family: inherit;
|
||||
font-size: 0.9rem;
|
||||
font-weight: 600;
|
||||
cursor: pointer;
|
||||
transition: opacity 0.15s ease;
|
||||
}
|
||||
|
||||
.confirm-dialog__btn:hover {
|
||||
opacity: 0.85;
|
||||
}
|
||||
|
||||
.confirm-dialog__btn--cancel {
|
||||
background: #e8e8e8;
|
||||
color: #555;
|
||||
}
|
||||
|
||||
.confirm-dialog__btn--confirm {
|
||||
background: #d32f2f;
|
||||
color: #fff;
|
||||
}
|
||||
|
||||
.confirm-dialog-enter-active,
|
||||
.confirm-dialog-leave-active {
|
||||
transition: opacity 0.15s ease;
|
||||
}
|
||||
|
||||
.confirm-dialog-enter-from,
|
||||
.confirm-dialog-leave-to {
|
||||
opacity: 0;
|
||||
}
|
||||
</style>
|
||||
49
frontend/src/components/CreateEventFab.vue
Normal file
49
frontend/src/components/CreateEventFab.vue
Normal file
@@ -0,0 +1,49 @@
|
||||
<template>
|
||||
<RouterLink to="/create" class="fab" aria-label="Create event">
|
||||
<span class="fab__icon" aria-hidden="true">+</span>
|
||||
</RouterLink>
|
||||
</template>
|
||||
|
||||
<script setup lang="ts">
|
||||
import { RouterLink } from 'vue-router'
|
||||
</script>
|
||||
|
||||
<style scoped>
|
||||
.fab {
|
||||
position: fixed;
|
||||
bottom: calc(1.2rem + env(safe-area-inset-bottom));
|
||||
right: 1.2rem;
|
||||
width: 56px;
|
||||
height: 56px;
|
||||
border-radius: 50%;
|
||||
background: var(--color-accent);
|
||||
color: #fff;
|
||||
display: flex;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
box-shadow: 0 4px 12px rgba(0, 0, 0, 0.25);
|
||||
text-decoration: none;
|
||||
z-index: 100;
|
||||
transition: transform 0.15s ease, box-shadow 0.15s ease;
|
||||
}
|
||||
|
||||
.fab:hover {
|
||||
transform: scale(1.08);
|
||||
box-shadow: 0 6px 16px rgba(0, 0, 0, 0.3);
|
||||
}
|
||||
|
||||
.fab:active {
|
||||
transform: scale(0.95);
|
||||
}
|
||||
|
||||
.fab:focus-visible {
|
||||
outline: 2px solid #fff;
|
||||
outline-offset: 3px;
|
||||
}
|
||||
|
||||
.fab__icon {
|
||||
font-size: 1.8rem;
|
||||
font-weight: 300;
|
||||
line-height: 1;
|
||||
}
|
||||
</style>
|
||||
19
frontend/src/components/DateSubheader.vue
Normal file
19
frontend/src/components/DateSubheader.vue
Normal file
@@ -0,0 +1,19 @@
|
||||
<template>
|
||||
<h3 class="date-subheader">{{ label }}</h3>
|
||||
</template>
|
||||
|
||||
<script setup lang="ts">
|
||||
defineProps<{
|
||||
label: string
|
||||
}>()
|
||||
</script>
|
||||
|
||||
<style scoped>
|
||||
.date-subheader {
|
||||
font-size: 0.85rem;
|
||||
font-weight: 500;
|
||||
color: rgba(255, 255, 255, 0.85);
|
||||
margin: 0;
|
||||
padding: var(--spacing-xs) 0;
|
||||
}
|
||||
</style>
|
||||
31
frontend/src/components/EmptyState.vue
Normal file
31
frontend/src/components/EmptyState.vue
Normal file
@@ -0,0 +1,31 @@
|
||||
<template>
|
||||
<div class="empty-state">
|
||||
<p class="empty-state__message">No events yet.<br />Create your first one!</p>
|
||||
<RouterLink to="/create" class="btn-primary empty-state__cta">+ Create Event</RouterLink>
|
||||
</div>
|
||||
</template>
|
||||
|
||||
<script setup lang="ts">
|
||||
import { RouterLink } from 'vue-router'
|
||||
</script>
|
||||
|
||||
<style scoped>
|
||||
.empty-state {
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
align-items: center;
|
||||
gap: var(--spacing-lg);
|
||||
}
|
||||
|
||||
.empty-state__message {
|
||||
font-size: 1rem;
|
||||
font-weight: 400;
|
||||
color: var(--color-text-on-gradient);
|
||||
opacity: 0.9;
|
||||
text-align: center;
|
||||
}
|
||||
|
||||
.empty-state__cta {
|
||||
max-width: 280px;
|
||||
}
|
||||
</style>
|
||||
181
frontend/src/components/EventCard.vue
Normal file
181
frontend/src/components/EventCard.vue
Normal file
@@ -0,0 +1,181 @@
|
||||
<template>
|
||||
<div
|
||||
class="event-card"
|
||||
:class="{ 'event-card--past': isPast, 'event-card--swiping': isSwiping }"
|
||||
:style="swipeStyle"
|
||||
@touchstart="onTouchStart"
|
||||
@touchmove="onTouchMove"
|
||||
@touchend="onTouchEnd"
|
||||
>
|
||||
<RouterLink :to="`/events/${eventToken}`" class="event-card__link">
|
||||
<span class="event-card__title">{{ title }}</span>
|
||||
<span class="event-card__time">{{ displayTime }}</span>
|
||||
</RouterLink>
|
||||
<span v-if="eventRole" class="event-card__badge" :class="`event-card__badge--${eventRole}`">
|
||||
{{ eventRole === 'organizer' ? 'Organizer' : 'Attendee' }}
|
||||
</span>
|
||||
<button
|
||||
class="event-card__delete"
|
||||
type="button"
|
||||
:aria-label="`Remove ${title}`"
|
||||
@click.stop="$emit('delete', eventToken)"
|
||||
>
|
||||
×
|
||||
</button>
|
||||
</div>
|
||||
</template>
|
||||
|
||||
<script setup lang="ts">
|
||||
import { ref, computed } from 'vue'
|
||||
import { RouterLink } from 'vue-router'
|
||||
|
||||
const props = defineProps<{
|
||||
eventToken: string
|
||||
title: string
|
||||
relativeTime: string
|
||||
isPast: boolean
|
||||
eventRole?: 'organizer' | 'attendee'
|
||||
timeDisplayMode?: 'clock' | 'relative'
|
||||
dateTime?: string
|
||||
}>()
|
||||
|
||||
const emit = defineEmits<{
|
||||
delete: [eventToken: string]
|
||||
}>()
|
||||
|
||||
const displayTime = computed(() => {
|
||||
if (props.timeDisplayMode === 'clock' && props.dateTime) {
|
||||
return new Intl.DateTimeFormat(undefined, { hour: '2-digit', minute: '2-digit' }).format(new Date(props.dateTime))
|
||||
}
|
||||
return props.relativeTime
|
||||
})
|
||||
|
||||
const SWIPE_THRESHOLD = 80
|
||||
|
||||
const startX = ref(0)
|
||||
const deltaX = ref(0)
|
||||
const isSwiping = ref(false)
|
||||
|
||||
const swipeStyle = computed(() => {
|
||||
if (deltaX.value === 0) return {}
|
||||
return { transform: `translateX(${deltaX.value}px)` }
|
||||
})
|
||||
|
||||
function onTouchStart(e: TouchEvent) {
|
||||
const touch = e.touches[0]
|
||||
if (!touch) return
|
||||
startX.value = touch.clientX
|
||||
deltaX.value = 0
|
||||
isSwiping.value = false
|
||||
}
|
||||
|
||||
function onTouchMove(e: TouchEvent) {
|
||||
const touch = e.touches[0]
|
||||
if (!touch) return
|
||||
const diff = touch.clientX - startX.value
|
||||
// Only allow leftward swipe
|
||||
if (diff < 0) {
|
||||
deltaX.value = diff
|
||||
isSwiping.value = true
|
||||
}
|
||||
}
|
||||
|
||||
function onTouchEnd() {
|
||||
if (deltaX.value < -SWIPE_THRESHOLD) {
|
||||
emit('delete', props.eventToken)
|
||||
}
|
||||
deltaX.value = 0
|
||||
isSwiping.value = false
|
||||
}
|
||||
</script>
|
||||
|
||||
<style scoped>
|
||||
.event-card {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
background: var(--color-card);
|
||||
border-radius: var(--radius-card);
|
||||
box-shadow: var(--shadow-card);
|
||||
padding: var(--spacing-md) var(--spacing-lg);
|
||||
gap: var(--spacing-sm);
|
||||
}
|
||||
|
||||
.event-card--past {
|
||||
opacity: 0.6;
|
||||
filter: saturate(0.5);
|
||||
}
|
||||
|
||||
.event-card:not(.event-card--swiping) {
|
||||
transition: opacity 0.2s ease, filter 0.2s ease, transform 0.2s ease;
|
||||
}
|
||||
|
||||
.event-card__link {
|
||||
flex: 1;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: 0.15rem;
|
||||
text-decoration: none;
|
||||
color: inherit;
|
||||
min-width: 0;
|
||||
}
|
||||
|
||||
.event-card__title {
|
||||
font-size: 0.95rem;
|
||||
font-weight: 600;
|
||||
color: var(--color-text);
|
||||
white-space: nowrap;
|
||||
overflow: hidden;
|
||||
text-overflow: ellipsis;
|
||||
}
|
||||
|
||||
.event-card__time {
|
||||
font-size: 0.8rem;
|
||||
font-weight: 400;
|
||||
color: #888;
|
||||
}
|
||||
|
||||
.event-card__badge {
|
||||
font-size: 0.7rem;
|
||||
font-weight: 600;
|
||||
padding: 0.15rem 0.5rem;
|
||||
border-radius: 999px;
|
||||
white-space: nowrap;
|
||||
flex-shrink: 0;
|
||||
}
|
||||
|
||||
.event-card__badge--organizer {
|
||||
background: var(--color-accent);
|
||||
color: #fff;
|
||||
}
|
||||
|
||||
.event-card__badge--attendee {
|
||||
background: #e0e0e0;
|
||||
color: #555;
|
||||
}
|
||||
|
||||
.event-card__delete {
|
||||
flex-shrink: 0;
|
||||
width: 28px;
|
||||
height: 28px;
|
||||
display: flex;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
background: none;
|
||||
border: none;
|
||||
font-size: 1.2rem;
|
||||
color: #bbb;
|
||||
cursor: pointer;
|
||||
border-radius: 50%;
|
||||
transition: color 0.15s ease, background 0.15s ease;
|
||||
}
|
||||
|
||||
.event-card__delete:hover {
|
||||
color: #d32f2f;
|
||||
background: rgba(211, 47, 47, 0.08);
|
||||
}
|
||||
|
||||
.event-card__delete:focus-visible {
|
||||
outline: 2px solid var(--color-accent);
|
||||
outline-offset: 2px;
|
||||
}
|
||||
</style>
|
||||
94
frontend/src/components/EventList.vue
Normal file
94
frontend/src/components/EventList.vue
Normal file
@@ -0,0 +1,94 @@
|
||||
<template>
|
||||
<div class="event-list">
|
||||
<section
|
||||
v-for="section in groupedSections"
|
||||
:key="section.key"
|
||||
:aria-label="section.label"
|
||||
class="event-section"
|
||||
>
|
||||
<SectionHeader :label="section.label" :emphasized="section.emphasized" />
|
||||
<div role="list">
|
||||
<template v-for="group in section.dateGroups" :key="group.dateKey">
|
||||
<DateSubheader v-if="group.showSubheader" :label="group.label" />
|
||||
<div v-for="event in group.events" :key="event.eventToken" role="listitem">
|
||||
<EventCard
|
||||
:event-token="event.eventToken"
|
||||
:title="event.title"
|
||||
:relative-time="formatRelativeTime(event.dateTime)"
|
||||
:is-past="section.key === 'past'"
|
||||
:event-role="getRole(event)"
|
||||
:time-display-mode="section.key === 'past' ? 'relative' : 'clock'"
|
||||
:date-time="event.dateTime"
|
||||
@delete="requestDelete"
|
||||
/>
|
||||
</div>
|
||||
</template>
|
||||
</div>
|
||||
</section>
|
||||
<ConfirmDialog
|
||||
:open="!!pendingDeleteToken"
|
||||
title="Remove event?"
|
||||
message="This event will be removed from your list."
|
||||
confirm-label="Remove"
|
||||
cancel-label="Cancel"
|
||||
@confirm="confirmDelete"
|
||||
@cancel="cancelDelete"
|
||||
/>
|
||||
</div>
|
||||
</template>
|
||||
|
||||
<script setup lang="ts">
|
||||
import { computed, ref } from 'vue'
|
||||
import { useEventStorage, isValidStoredEvent } from '../composables/useEventStorage'
|
||||
import { useEventGrouping } from '../composables/useEventGrouping'
|
||||
import { formatRelativeTime } from '../composables/useRelativeTime'
|
||||
import EventCard from './EventCard.vue'
|
||||
import SectionHeader from './SectionHeader.vue'
|
||||
import DateSubheader from './DateSubheader.vue'
|
||||
import ConfirmDialog from './ConfirmDialog.vue'
|
||||
import type { StoredEvent } from '../composables/useEventStorage'
|
||||
|
||||
const { getStoredEvents, removeEvent } = useEventStorage()
|
||||
|
||||
const pendingDeleteToken = ref<string | null>(null)
|
||||
|
||||
function requestDelete(eventToken: string) {
|
||||
pendingDeleteToken.value = eventToken
|
||||
}
|
||||
|
||||
function confirmDelete() {
|
||||
if (pendingDeleteToken.value) {
|
||||
removeEvent(pendingDeleteToken.value)
|
||||
}
|
||||
pendingDeleteToken.value = null
|
||||
}
|
||||
|
||||
function cancelDelete() {
|
||||
pendingDeleteToken.value = null
|
||||
}
|
||||
|
||||
function getRole(event: StoredEvent): 'organizer' | 'attendee' | undefined {
|
||||
if (event.organizerToken) return 'organizer'
|
||||
if (event.rsvpToken) return 'attendee'
|
||||
return undefined
|
||||
}
|
||||
|
||||
const groupedSections = computed(() => {
|
||||
const valid = getStoredEvents().filter(isValidStoredEvent)
|
||||
return useEventGrouping(valid)
|
||||
})
|
||||
</script>
|
||||
|
||||
<style scoped>
|
||||
.event-list {
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: var(--spacing-md);
|
||||
}
|
||||
|
||||
.event-section [role="list"] {
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: var(--spacing-sm);
|
||||
}
|
||||
</style>
|
||||
75
frontend/src/components/RsvpBar.vue
Normal file
75
frontend/src/components/RsvpBar.vue
Normal file
@@ -0,0 +1,75 @@
|
||||
<template>
|
||||
<div class="rsvp-bar">
|
||||
<div class="rsvp-bar__inner">
|
||||
<!-- Status state: already RSVPed -->
|
||||
<div v-if="hasRsvp" class="rsvp-bar__status">
|
||||
<span class="rsvp-bar__check" aria-hidden="true">✓</span>
|
||||
<span class="rsvp-bar__text">You're attending!</span>
|
||||
</div>
|
||||
|
||||
<!-- CTA state: no RSVP yet -->
|
||||
<button v-else class="btn-primary rsvp-bar__cta" type="button" @click="$emit('open')">
|
||||
I'm attending
|
||||
</button>
|
||||
</div>
|
||||
</div>
|
||||
</template>
|
||||
|
||||
<script setup lang="ts">
|
||||
defineProps<{
|
||||
hasRsvp?: boolean
|
||||
}>()
|
||||
|
||||
defineEmits<{
|
||||
open: []
|
||||
}>()
|
||||
</script>
|
||||
|
||||
<style scoped>
|
||||
.rsvp-bar {
|
||||
position: fixed;
|
||||
bottom: 0;
|
||||
left: 0;
|
||||
right: 0;
|
||||
display: flex;
|
||||
justify-content: center;
|
||||
z-index: 50;
|
||||
padding: var(--spacing-md) var(--content-padding);
|
||||
padding-bottom: calc(var(--spacing-md) + env(safe-area-inset-bottom, 0px));
|
||||
}
|
||||
|
||||
.rsvp-bar__inner {
|
||||
width: 100%;
|
||||
max-width: var(--content-max-width);
|
||||
}
|
||||
|
||||
.rsvp-bar__cta {
|
||||
width: 100%;
|
||||
}
|
||||
|
||||
.rsvp-bar__status {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
gap: var(--spacing-xs);
|
||||
background: var(--color-card);
|
||||
border-radius: var(--radius-card);
|
||||
padding: var(--spacing-md) var(--spacing-lg);
|
||||
box-shadow: var(--shadow-card);
|
||||
font-weight: 600;
|
||||
font-size: 0.95rem;
|
||||
color: var(--color-text);
|
||||
}
|
||||
|
||||
.rsvp-bar__check {
|
||||
color: #4caf50;
|
||||
font-size: 1.1rem;
|
||||
font-weight: 700;
|
||||
}
|
||||
|
||||
.rsvp-bar__text {
|
||||
overflow: hidden;
|
||||
text-overflow: ellipsis;
|
||||
white-space: nowrap;
|
||||
}
|
||||
</style>
|
||||
27
frontend/src/components/SectionHeader.vue
Normal file
27
frontend/src/components/SectionHeader.vue
Normal file
@@ -0,0 +1,27 @@
|
||||
<template>
|
||||
<h2 class="section-header" :class="{ 'section-header--emphasized': emphasized }">
|
||||
{{ label }}
|
||||
</h2>
|
||||
</template>
|
||||
|
||||
<script setup lang="ts">
|
||||
defineProps<{
|
||||
label: string
|
||||
emphasized?: boolean
|
||||
}>()
|
||||
</script>
|
||||
|
||||
<style scoped>
|
||||
.section-header {
|
||||
font-size: 1rem;
|
||||
font-weight: 700;
|
||||
color: var(--color-text);
|
||||
margin: 0;
|
||||
padding: var(--spacing-sm) 0;
|
||||
}
|
||||
|
||||
.section-header--emphasized {
|
||||
font-size: 1.1rem;
|
||||
font-weight: 800;
|
||||
}
|
||||
</style>
|
||||
51
frontend/src/components/__tests__/BottomSheet.spec.ts
Normal file
51
frontend/src/components/__tests__/BottomSheet.spec.ts
Normal file
@@ -0,0 +1,51 @@
|
||||
import { describe, it, expect } from 'vitest'
|
||||
import { mount } from '@vue/test-utils'
|
||||
import BottomSheet from '../BottomSheet.vue'
|
||||
|
||||
function mountSheet(open = true) {
|
||||
return mount(BottomSheet, {
|
||||
props: { open, label: 'Test Sheet' },
|
||||
slots: { default: '<p>Sheet content</p>' },
|
||||
attachTo: document.body,
|
||||
})
|
||||
}
|
||||
|
||||
describe('BottomSheet', () => {
|
||||
it('renders slot content when open', () => {
|
||||
const wrapper = mountSheet(true)
|
||||
expect(document.body.textContent).toContain('Sheet content')
|
||||
wrapper.unmount()
|
||||
})
|
||||
|
||||
it('does not render content when closed', () => {
|
||||
const wrapper = mountSheet(false)
|
||||
expect(document.body.querySelector('[role="dialog"]')).toBeNull()
|
||||
wrapper.unmount()
|
||||
})
|
||||
|
||||
it('has aria-modal and aria-label on the dialog', () => {
|
||||
const wrapper = mountSheet(true)
|
||||
const dialog = document.body.querySelector('[role="dialog"]')!
|
||||
expect(dialog.getAttribute('aria-modal')).toBe('true')
|
||||
expect(dialog.getAttribute('aria-label')).toBe('Test Sheet')
|
||||
wrapper.unmount()
|
||||
})
|
||||
|
||||
it('emits close when backdrop is clicked', async () => {
|
||||
const wrapper = mountSheet(true)
|
||||
const backdrop = document.body.querySelector('.sheet-backdrop')! as HTMLElement
|
||||
await backdrop.click()
|
||||
// Vue test utils tracks emitted events on the wrapper
|
||||
expect(wrapper.emitted('close')).toBeTruthy()
|
||||
wrapper.unmount()
|
||||
})
|
||||
|
||||
it('emits close on Escape key', async () => {
|
||||
const wrapper = mountSheet(true)
|
||||
const backdrop = document.body.querySelector('.sheet-backdrop')! as HTMLElement
|
||||
backdrop.dispatchEvent(new KeyboardEvent('keydown', { key: 'Escape', bubbles: true }))
|
||||
await wrapper.vm.$nextTick()
|
||||
expect(wrapper.emitted('close')).toBeTruthy()
|
||||
wrapper.unmount()
|
||||
})
|
||||
})
|
||||
111
frontend/src/components/__tests__/ConfirmDialog.spec.ts
Normal file
111
frontend/src/components/__tests__/ConfirmDialog.spec.ts
Normal file
@@ -0,0 +1,111 @@
|
||||
import { describe, it, expect, afterEach } from 'vitest'
|
||||
import { mount, VueWrapper } from '@vue/test-utils'
|
||||
import ConfirmDialog from '../ConfirmDialog.vue'
|
||||
|
||||
let wrapper: VueWrapper
|
||||
|
||||
function mountDialog(props: Record<string, unknown> = {}) {
|
||||
wrapper = mount(ConfirmDialog, {
|
||||
props: {
|
||||
open: true,
|
||||
...props,
|
||||
},
|
||||
attachTo: document.body,
|
||||
})
|
||||
return wrapper
|
||||
}
|
||||
|
||||
function dialog() {
|
||||
return document.body.querySelector('.confirm-dialog')
|
||||
}
|
||||
|
||||
function overlay() {
|
||||
return document.body.querySelector('.confirm-dialog__overlay')
|
||||
}
|
||||
|
||||
afterEach(() => {
|
||||
wrapper?.unmount()
|
||||
})
|
||||
|
||||
describe('ConfirmDialog', () => {
|
||||
it('renders when open is true', () => {
|
||||
mountDialog()
|
||||
expect(dialog()).not.toBeNull()
|
||||
})
|
||||
|
||||
it('does not render when open is false', () => {
|
||||
mountDialog({ open: false })
|
||||
expect(dialog()).toBeNull()
|
||||
})
|
||||
|
||||
it('displays default title', () => {
|
||||
mountDialog()
|
||||
expect(dialog()!.querySelector('.confirm-dialog__title')!.textContent).toBe('Are you sure?')
|
||||
})
|
||||
|
||||
it('displays custom title and message', () => {
|
||||
mountDialog({
|
||||
title: 'Remove event?',
|
||||
message: 'This cannot be undone.',
|
||||
})
|
||||
expect(dialog()!.querySelector('.confirm-dialog__title')!.textContent).toBe('Remove event?')
|
||||
expect(dialog()!.querySelector('.confirm-dialog__message')!.textContent).toBe('This cannot be undone.')
|
||||
})
|
||||
|
||||
it('displays custom button labels', () => {
|
||||
mountDialog({
|
||||
confirmLabel: 'Delete',
|
||||
cancelLabel: 'Keep',
|
||||
})
|
||||
const buttons = dialog()!.querySelectorAll('.confirm-dialog__btn')
|
||||
expect(buttons[0]!.textContent!.trim()).toBe('Keep')
|
||||
expect(buttons[1]!.textContent!.trim()).toBe('Delete')
|
||||
})
|
||||
|
||||
it('emits confirm when confirm button is clicked', async () => {
|
||||
mountDialog()
|
||||
const btn = dialog()!.querySelector('.confirm-dialog__btn--confirm') as HTMLElement
|
||||
btn.click()
|
||||
await wrapper.vm.$nextTick()
|
||||
expect(wrapper.emitted('confirm')).toHaveLength(1)
|
||||
})
|
||||
|
||||
it('emits cancel when cancel button is clicked', async () => {
|
||||
mountDialog()
|
||||
const btn = dialog()!.querySelector('.confirm-dialog__btn--cancel') as HTMLElement
|
||||
btn.click()
|
||||
await wrapper.vm.$nextTick()
|
||||
expect(wrapper.emitted('cancel')).toHaveLength(1)
|
||||
})
|
||||
|
||||
it('emits cancel when overlay is clicked', async () => {
|
||||
mountDialog()
|
||||
const el = overlay() as HTMLElement
|
||||
el.click()
|
||||
await wrapper.vm.$nextTick()
|
||||
expect(wrapper.emitted('cancel')).toHaveLength(1)
|
||||
})
|
||||
|
||||
it('emits cancel when Escape key is pressed', async () => {
|
||||
mountDialog()
|
||||
const el = dialog() as HTMLElement
|
||||
el.dispatchEvent(new KeyboardEvent('keydown', { key: 'Escape', bubbles: true }))
|
||||
await wrapper.vm.$nextTick()
|
||||
expect(wrapper.emitted('cancel')).toHaveLength(1)
|
||||
})
|
||||
|
||||
it('focuses cancel button when opened', async () => {
|
||||
mountDialog({ open: false })
|
||||
await wrapper.setProps({ open: true })
|
||||
await wrapper.vm.$nextTick()
|
||||
const cancelBtn = dialog()!.querySelector('.confirm-dialog__btn--cancel')
|
||||
expect(document.activeElement).toBe(cancelBtn)
|
||||
})
|
||||
|
||||
it('has alertdialog role and aria-modal', () => {
|
||||
mountDialog()
|
||||
const el = dialog() as HTMLElement
|
||||
expect(el.getAttribute('role')).toBe('alertdialog')
|
||||
expect(el.getAttribute('aria-modal')).toBe('true')
|
||||
})
|
||||
})
|
||||
17
frontend/src/components/__tests__/DateSubheader.spec.ts
Normal file
17
frontend/src/components/__tests__/DateSubheader.spec.ts
Normal file
@@ -0,0 +1,17 @@
|
||||
import { describe, it, expect } from 'vitest'
|
||||
import { mount } from '@vue/test-utils'
|
||||
import DateSubheader from '../DateSubheader.vue'
|
||||
|
||||
describe('DateSubheader', () => {
|
||||
it('renders the date label as an h3', () => {
|
||||
const wrapper = mount(DateSubheader, { props: { label: 'Wed, 12 Mar' } })
|
||||
const h3 = wrapper.find('h3')
|
||||
expect(h3.exists()).toBe(true)
|
||||
expect(h3.text()).toBe('Wed, 12 Mar')
|
||||
})
|
||||
|
||||
it('applies the date-subheader class', () => {
|
||||
const wrapper = mount(DateSubheader, { props: { label: 'Fri, 14 Mar' } })
|
||||
expect(wrapper.find('.date-subheader').exists()).toBe(true)
|
||||
})
|
||||
})
|
||||
35
frontend/src/components/__tests__/EmptyState.spec.ts
Normal file
35
frontend/src/components/__tests__/EmptyState.spec.ts
Normal file
@@ -0,0 +1,35 @@
|
||||
import { describe, it, expect } from 'vitest'
|
||||
import { mount } from '@vue/test-utils'
|
||||
import { createRouter, createMemoryHistory } from 'vue-router'
|
||||
import EmptyState from '../EmptyState.vue'
|
||||
|
||||
const router = createRouter({
|
||||
history: createMemoryHistory(),
|
||||
routes: [
|
||||
{ path: '/', component: { template: '<div />' } },
|
||||
{ path: '/create', name: 'create', component: { template: '<div />' } },
|
||||
],
|
||||
})
|
||||
|
||||
function mountEmptyState() {
|
||||
return mount(EmptyState, {
|
||||
global: {
|
||||
plugins: [router],
|
||||
},
|
||||
})
|
||||
}
|
||||
|
||||
describe('EmptyState', () => {
|
||||
it('renders an inviting message', () => {
|
||||
const wrapper = mountEmptyState()
|
||||
expect(wrapper.text()).toContain('No events yet')
|
||||
})
|
||||
|
||||
it('renders a Create Event link', () => {
|
||||
const wrapper = mountEmptyState()
|
||||
const link = wrapper.find('a')
|
||||
expect(link.exists()).toBe(true)
|
||||
expect(link.text()).toContain('Create Event')
|
||||
expect(link.attributes('href')).toBe('/create')
|
||||
})
|
||||
})
|
||||
100
frontend/src/components/__tests__/EventCard.spec.ts
Normal file
100
frontend/src/components/__tests__/EventCard.spec.ts
Normal file
@@ -0,0 +1,100 @@
|
||||
import { describe, it, expect } from 'vitest'
|
||||
import { mount } from '@vue/test-utils'
|
||||
import { createRouter, createMemoryHistory } from 'vue-router'
|
||||
import EventCard from '../EventCard.vue'
|
||||
|
||||
const router = createRouter({
|
||||
history: createMemoryHistory(),
|
||||
routes: [
|
||||
{ path: '/', component: { template: '<div />' } },
|
||||
{ path: '/events/:eventToken', name: 'event', component: { template: '<div />' } },
|
||||
],
|
||||
})
|
||||
|
||||
function mountCard(props: Record<string, unknown> = {}) {
|
||||
return mount(EventCard, {
|
||||
props: {
|
||||
eventToken: 'abc-123',
|
||||
title: 'Birthday Party',
|
||||
relativeTime: 'in 3 days',
|
||||
isPast: false,
|
||||
...props,
|
||||
},
|
||||
global: {
|
||||
plugins: [router],
|
||||
},
|
||||
})
|
||||
}
|
||||
|
||||
describe('EventCard', () => {
|
||||
it('renders the event title', () => {
|
||||
const wrapper = mountCard()
|
||||
expect(wrapper.text()).toContain('Birthday Party')
|
||||
})
|
||||
|
||||
it('renders relative time', () => {
|
||||
const wrapper = mountCard({ relativeTime: 'yesterday' })
|
||||
expect(wrapper.text()).toContain('yesterday')
|
||||
})
|
||||
|
||||
it('links to the event detail page', () => {
|
||||
const wrapper = mountCard({ eventToken: 'xyz-789' })
|
||||
const link = wrapper.find('a')
|
||||
expect(link.attributes('href')).toBe('/events/xyz-789')
|
||||
})
|
||||
|
||||
it('applies past modifier class when isPast is true', () => {
|
||||
const wrapper = mountCard({ isPast: true })
|
||||
expect(wrapper.find('.event-card--past').exists()).toBe(true)
|
||||
})
|
||||
|
||||
it('does not apply past modifier class when isPast is false', () => {
|
||||
const wrapper = mountCard({ isPast: false })
|
||||
expect(wrapper.find('.event-card--past').exists()).toBe(false)
|
||||
})
|
||||
|
||||
it('renders organizer badge when eventRole is organizer', () => {
|
||||
const wrapper = mountCard({ eventRole: 'organizer' })
|
||||
expect(wrapper.text()).toContain('Organizer')
|
||||
})
|
||||
|
||||
it('renders attendee badge when eventRole is attendee', () => {
|
||||
const wrapper = mountCard({ eventRole: 'attendee' })
|
||||
expect(wrapper.text()).toContain('Attendee')
|
||||
})
|
||||
|
||||
it('renders no badge when eventRole is undefined', () => {
|
||||
const wrapper = mountCard({ eventRole: undefined })
|
||||
expect(wrapper.find('.event-card__badge').exists()).toBe(false)
|
||||
})
|
||||
|
||||
it('emits delete event with eventToken when delete button is clicked', async () => {
|
||||
const wrapper = mountCard({ eventToken: 'abc-123' })
|
||||
await wrapper.find('.event-card__delete').trigger('click')
|
||||
expect(wrapper.emitted('delete')).toEqual([['abc-123']])
|
||||
})
|
||||
|
||||
it('displays clock time when timeDisplayMode is clock', () => {
|
||||
const wrapper = mountCard({
|
||||
timeDisplayMode: 'clock',
|
||||
dateTime: '2026-03-11T18:30:00',
|
||||
})
|
||||
const timeText = wrapper.find('.event-card__time').text()
|
||||
// Locale-dependent: could be "18:30" or "06:30 PM"
|
||||
expect(timeText).toMatch(/(?:18.30|6.30\s*PM)/i)
|
||||
})
|
||||
|
||||
it('displays relative time when timeDisplayMode is relative', () => {
|
||||
const wrapper = mountCard({
|
||||
relativeTime: '3 days ago',
|
||||
timeDisplayMode: 'relative',
|
||||
dateTime: '2026-03-08T10:00:00',
|
||||
})
|
||||
expect(wrapper.find('.event-card__time').text()).toBe('3 days ago')
|
||||
})
|
||||
|
||||
it('falls back to relativeTime when timeDisplayMode is not set', () => {
|
||||
const wrapper = mountCard({ relativeTime: 'in 3 days' })
|
||||
expect(wrapper.find('.event-card__time').text()).toBe('in 3 days')
|
||||
})
|
||||
})
|
||||
140
frontend/src/components/__tests__/EventList.spec.ts
Normal file
140
frontend/src/components/__tests__/EventList.spec.ts
Normal file
@@ -0,0 +1,140 @@
|
||||
import { describe, it, expect, vi, beforeEach, afterEach } from 'vitest'
|
||||
import { mount } from '@vue/test-utils'
|
||||
import { createRouter, createMemoryHistory } from 'vue-router'
|
||||
import EventList from '../EventList.vue'
|
||||
|
||||
const router = createRouter({
|
||||
history: createMemoryHistory(),
|
||||
routes: [
|
||||
{ path: '/', component: { template: '<div />' } },
|
||||
{ path: '/events/:eventToken', name: 'event', component: { template: '<div />' } },
|
||||
],
|
||||
})
|
||||
|
||||
// Fixed "now": Wednesday, 2026-03-11 12:00
|
||||
const NOW = new Date(2026, 2, 11, 12, 0, 0)
|
||||
|
||||
const mockEvents = [
|
||||
{ eventToken: 'past-1', title: 'Past Event', dateTime: '2026-03-01T10:00:00', expiryDate: '' },
|
||||
{ eventToken: 'later-1', title: 'Later Event', dateTime: '2027-06-15T10:00:00', expiryDate: '' },
|
||||
{ eventToken: 'today-1', title: 'Today Event', dateTime: '2026-03-11T18:00:00', expiryDate: '' },
|
||||
{ eventToken: 'week-1', title: 'This Week Event', dateTime: '2026-03-13T10:00:00', expiryDate: '' },
|
||||
{ eventToken: 'nextweek-1', title: 'Next Week Event', dateTime: '2026-03-16T10:00:00', expiryDate: '' },
|
||||
]
|
||||
|
||||
vi.mock('../../composables/useEventStorage', () => ({
|
||||
isValidStoredEvent: (e: unknown) => {
|
||||
if (typeof e !== 'object' || e === null) return false
|
||||
const obj = e as Record<string, unknown>
|
||||
return typeof obj.eventToken === 'string' && obj.eventToken.length > 0
|
||||
&& typeof obj.title === 'string' && obj.title.length > 0
|
||||
&& typeof obj.dateTime === 'string' && obj.dateTime.length > 0
|
||||
},
|
||||
useEventStorage: () => ({
|
||||
getStoredEvents: () => mockEvents,
|
||||
removeEvent: vi.fn(),
|
||||
}),
|
||||
}))
|
||||
|
||||
vi.mock('../../composables/useRelativeTime', () => ({
|
||||
formatRelativeTime: (dateTime: string) => {
|
||||
if (dateTime.includes('03-01')) return '10 days ago'
|
||||
if (dateTime.includes('06-15')) return 'in 1 year'
|
||||
if (dateTime.includes('03-11')) return 'in 6 hours'
|
||||
if (dateTime.includes('03-13')) return 'in 2 days'
|
||||
if (dateTime.includes('03-16')) return 'in 5 days'
|
||||
return 'sometime'
|
||||
},
|
||||
}))
|
||||
|
||||
function mountList() {
|
||||
return mount(EventList, {
|
||||
global: { plugins: [router] },
|
||||
})
|
||||
}
|
||||
|
||||
describe('EventList', () => {
|
||||
beforeEach(() => {
|
||||
vi.useFakeTimers()
|
||||
vi.setSystemTime(NOW)
|
||||
})
|
||||
|
||||
afterEach(() => {
|
||||
vi.useRealTimers()
|
||||
})
|
||||
|
||||
it('renders section headers for each non-empty section', () => {
|
||||
const wrapper = mountList()
|
||||
const headers = wrapper.findAll('.section-header')
|
||||
expect(headers).toHaveLength(5)
|
||||
expect(headers[0]!.text()).toBe('Today')
|
||||
expect(headers[1]!.text()).toBe('This Week')
|
||||
expect(headers[2]!.text()).toBe('Next Week')
|
||||
expect(headers[3]!.text()).toBe('Later')
|
||||
expect(headers[4]!.text()).toBe('Past')
|
||||
})
|
||||
|
||||
it('renders events within their correct sections', () => {
|
||||
const wrapper = mountList()
|
||||
const sections = wrapper.findAll('.event-section')
|
||||
expect(sections).toHaveLength(5)
|
||||
|
||||
expect(sections[0]!.text()).toContain('Today Event')
|
||||
expect(sections[1]!.text()).toContain('This Week Event')
|
||||
expect(sections[2]!.text()).toContain('Next Week Event')
|
||||
expect(sections[3]!.text()).toContain('Later Event')
|
||||
expect(sections[4]!.text()).toContain('Past Event')
|
||||
})
|
||||
|
||||
it('renders all valid events as cards', () => {
|
||||
const wrapper = mountList()
|
||||
const cards = wrapper.findAll('.event-card')
|
||||
expect(cards).toHaveLength(5)
|
||||
})
|
||||
|
||||
it('marks past events with isPast class', () => {
|
||||
const wrapper = mountList()
|
||||
const pastSection = wrapper.findAll('.event-section')[4]!
|
||||
const pastCards = pastSection.findAll('.event-card')
|
||||
expect(pastCards).toHaveLength(1)
|
||||
expect(pastCards[0]!.classes()).toContain('event-card--past')
|
||||
})
|
||||
|
||||
it('does not mark non-past events with isPast class', () => {
|
||||
const wrapper = mountList()
|
||||
const todaySection = wrapper.findAll('.event-section')[0]!
|
||||
const cards = todaySection.findAll('.event-card')
|
||||
expect(cards[0]!.classes()).not.toContain('event-card--past')
|
||||
})
|
||||
|
||||
it('sections have aria-label attributes', () => {
|
||||
const wrapper = mountList()
|
||||
const sections = wrapper.findAll('section')
|
||||
expect(sections[0]!.attributes('aria-label')).toBe('Today')
|
||||
expect(sections[1]!.attributes('aria-label')).toBe('This Week')
|
||||
expect(sections[2]!.attributes('aria-label')).toBe('Next Week')
|
||||
expect(sections[3]!.attributes('aria-label')).toBe('Later')
|
||||
expect(sections[4]!.attributes('aria-label')).toBe('Past')
|
||||
})
|
||||
|
||||
it('does not render date subheader in "Today" section', () => {
|
||||
const wrapper = mountList()
|
||||
const todaySection = wrapper.findAll('.event-section')[0]!
|
||||
expect(todaySection.find('.date-subheader').exists()).toBe(false)
|
||||
})
|
||||
|
||||
it('renders date subheaders in non-today sections', () => {
|
||||
const wrapper = mountList()
|
||||
const thisWeekSection = wrapper.findAll('.event-section')[1]!
|
||||
expect(thisWeekSection.find('.date-subheader').exists()).toBe(true)
|
||||
|
||||
const nextWeekSection = wrapper.findAll('.event-section')[2]!
|
||||
expect(nextWeekSection.find('.date-subheader').exists()).toBe(true)
|
||||
|
||||
const laterSection = wrapper.findAll('.event-section')[3]!
|
||||
expect(laterSection.find('.date-subheader').exists()).toBe(true)
|
||||
|
||||
const pastSection = wrapper.findAll('.event-section')[4]!
|
||||
expect(pastSection.find('.date-subheader').exists()).toBe(true)
|
||||
})
|
||||
})
|
||||
30
frontend/src/components/__tests__/RsvpBar.spec.ts
Normal file
30
frontend/src/components/__tests__/RsvpBar.spec.ts
Normal file
@@ -0,0 +1,30 @@
|
||||
import { describe, it, expect } from 'vitest'
|
||||
import { mount } from '@vue/test-utils'
|
||||
import RsvpBar from '../RsvpBar.vue'
|
||||
|
||||
describe('RsvpBar', () => {
|
||||
it('renders CTA button when hasRsvp is false', () => {
|
||||
const wrapper = mount(RsvpBar)
|
||||
expect(wrapper.find('.rsvp-bar__cta').exists()).toBe(true)
|
||||
expect(wrapper.find('.rsvp-bar__cta').text()).toBe("I'm attending")
|
||||
expect(wrapper.find('.rsvp-bar__status').exists()).toBe(false)
|
||||
})
|
||||
|
||||
it('renders status text when hasRsvp is true', () => {
|
||||
const wrapper = mount(RsvpBar, { props: { hasRsvp: true } })
|
||||
expect(wrapper.find('.rsvp-bar__status').exists()).toBe(true)
|
||||
expect(wrapper.find('.rsvp-bar__text').text()).toBe("You're attending!")
|
||||
expect(wrapper.find('.rsvp-bar__cta').exists()).toBe(false)
|
||||
})
|
||||
|
||||
it('emits open when CTA button is clicked', async () => {
|
||||
const wrapper = mount(RsvpBar)
|
||||
await wrapper.find('.rsvp-bar__cta').trigger('click')
|
||||
expect(wrapper.emitted('open')).toHaveLength(1)
|
||||
})
|
||||
|
||||
it('does not render CTA button when hasRsvp is true', () => {
|
||||
const wrapper = mount(RsvpBar, { props: { hasRsvp: true } })
|
||||
expect(wrapper.find('button').exists()).toBe(false)
|
||||
})
|
||||
})
|
||||
27
frontend/src/components/__tests__/SectionHeader.spec.ts
Normal file
27
frontend/src/components/__tests__/SectionHeader.spec.ts
Normal file
@@ -0,0 +1,27 @@
|
||||
import { describe, it, expect } from 'vitest'
|
||||
import { mount } from '@vue/test-utils'
|
||||
import SectionHeader from '../SectionHeader.vue'
|
||||
|
||||
describe('SectionHeader', () => {
|
||||
it('renders the section label as an h2', () => {
|
||||
const wrapper = mount(SectionHeader, { props: { label: 'Today' } })
|
||||
const h2 = wrapper.find('h2')
|
||||
expect(h2.exists()).toBe(true)
|
||||
expect(h2.text()).toBe('Today')
|
||||
})
|
||||
|
||||
it('does not apply emphasized class by default', () => {
|
||||
const wrapper = mount(SectionHeader, { props: { label: 'Later' } })
|
||||
expect(wrapper.find('.section-header--emphasized').exists()).toBe(false)
|
||||
})
|
||||
|
||||
it('applies emphasized class when emphasized prop is true', () => {
|
||||
const wrapper = mount(SectionHeader, { props: { label: 'Today', emphasized: true } })
|
||||
expect(wrapper.find('.section-header--emphasized').exists()).toBe(true)
|
||||
})
|
||||
|
||||
it('does not apply emphasized class when emphasized prop is false', () => {
|
||||
const wrapper = mount(SectionHeader, { props: { label: 'Past', emphasized: false } })
|
||||
expect(wrapper.find('.section-header--emphasized').exists()).toBe(false)
|
||||
})
|
||||
})
|
||||
158
frontend/src/components/__tests__/useEventGrouping.spec.ts
Normal file
158
frontend/src/components/__tests__/useEventGrouping.spec.ts
Normal file
@@ -0,0 +1,158 @@
|
||||
import { describe, it, expect, vi, beforeEach, afterEach } from 'vitest'
|
||||
import { useEventGrouping } from '../../composables/useEventGrouping'
|
||||
import type { StoredEvent } from '../../composables/useEventStorage'
|
||||
|
||||
function makeEvent(overrides: Partial<StoredEvent> & { dateTime: string }): StoredEvent {
|
||||
return {
|
||||
eventToken: `evt-${Math.random().toString(36).slice(2, 8)}`,
|
||||
title: 'Test Event',
|
||||
expiryDate: '',
|
||||
...overrides,
|
||||
}
|
||||
}
|
||||
|
||||
describe('useEventGrouping', () => {
|
||||
// Fixed "now": Wednesday, 2026-03-11 12:00 local
|
||||
const NOW = new Date(2026, 2, 11, 12, 0, 0)
|
||||
|
||||
beforeEach(() => {
|
||||
vi.useFakeTimers()
|
||||
vi.setSystemTime(NOW)
|
||||
})
|
||||
|
||||
afterEach(() => {
|
||||
vi.useRealTimers()
|
||||
})
|
||||
|
||||
it('returns empty array when no events', () => {
|
||||
const sections = useEventGrouping([], NOW)
|
||||
expect(sections).toEqual([])
|
||||
})
|
||||
|
||||
it('classifies a today event into "today" section', () => {
|
||||
const event = makeEvent({ dateTime: '2026-03-11T18:30:00' })
|
||||
const sections = useEventGrouping([event], NOW)
|
||||
expect(sections).toHaveLength(1)
|
||||
expect(sections[0]!.key).toBe('today')
|
||||
expect(sections[0]!.label).toBe('Today')
|
||||
expect(sections[0]!.dateGroups[0]!.events).toHaveLength(1)
|
||||
})
|
||||
|
||||
it('classifies events into all five sections', () => {
|
||||
const events = [
|
||||
makeEvent({ title: 'Today', dateTime: '2026-03-11T10:00:00' }),
|
||||
makeEvent({ title: 'This Week', dateTime: '2026-03-13T10:00:00' }), // Friday (same week)
|
||||
makeEvent({ title: 'Next Week', dateTime: '2026-03-16T10:00:00' }), // Monday next week
|
||||
makeEvent({ title: 'Later', dateTime: '2026-03-30T10:00:00' }), // far future
|
||||
makeEvent({ title: 'Past', dateTime: '2026-03-09T10:00:00' }), // Monday (past)
|
||||
]
|
||||
const sections = useEventGrouping(events, NOW)
|
||||
expect(sections).toHaveLength(5)
|
||||
expect(sections[0]!.key).toBe('today')
|
||||
expect(sections[1]!.key).toBe('thisWeek')
|
||||
expect(sections[2]!.key).toBe('nextWeek')
|
||||
expect(sections[3]!.key).toBe('later')
|
||||
expect(sections[4]!.key).toBe('past')
|
||||
})
|
||||
|
||||
it('omits empty sections', () => {
|
||||
const events = [
|
||||
makeEvent({ title: 'Today', dateTime: '2026-03-11T10:00:00' }),
|
||||
makeEvent({ title: 'Past', dateTime: '2026-03-01T10:00:00' }),
|
||||
]
|
||||
const sections = useEventGrouping(events, NOW)
|
||||
expect(sections).toHaveLength(2)
|
||||
expect(sections[0]!.key).toBe('today')
|
||||
expect(sections[1]!.key).toBe('past')
|
||||
})
|
||||
|
||||
it('sorts upcoming events ascending by time', () => {
|
||||
const events = [
|
||||
makeEvent({ title: 'Later', dateTime: '2026-03-11T20:00:00' }),
|
||||
makeEvent({ title: 'Earlier', dateTime: '2026-03-11T08:00:00' }),
|
||||
]
|
||||
const sections = useEventGrouping(events, NOW)
|
||||
const todayEvents = sections[0]!.dateGroups[0]!.events
|
||||
expect(todayEvents[0]!.title).toBe('Earlier')
|
||||
expect(todayEvents[1]!.title).toBe('Later')
|
||||
})
|
||||
|
||||
it('sorts past events descending by time (most recent first)', () => {
|
||||
const events = [
|
||||
makeEvent({ title: 'Older', dateTime: '2026-03-01T10:00:00' }),
|
||||
makeEvent({ title: 'Newer', dateTime: '2026-03-09T10:00:00' }),
|
||||
]
|
||||
const sections = useEventGrouping(events, NOW)
|
||||
const pastEvents = sections[0]!.dateGroups
|
||||
expect(pastEvents[0]!.events[0]!.title).toBe('Newer')
|
||||
expect(pastEvents[1]!.events[0]!.title).toBe('Older')
|
||||
})
|
||||
|
||||
it('groups events by date within a section', () => {
|
||||
const events = [
|
||||
makeEvent({ title: 'Fri AM', dateTime: '2026-03-13T09:00:00' }),
|
||||
makeEvent({ title: 'Fri PM', dateTime: '2026-03-13T18:00:00' }),
|
||||
makeEvent({ title: 'Sat', dateTime: '2026-03-14T12:00:00' }),
|
||||
]
|
||||
const sections = useEventGrouping(events, NOW)
|
||||
expect(sections[0]!.key).toBe('thisWeek')
|
||||
const dateGroups = sections[0]!.dateGroups
|
||||
expect(dateGroups).toHaveLength(2) // Friday and Saturday
|
||||
expect(dateGroups[0]!.events).toHaveLength(2) // Two Friday events
|
||||
expect(dateGroups[1]!.events).toHaveLength(1) // One Saturday event
|
||||
})
|
||||
|
||||
it('sets showSubheader=false for "today" section', () => {
|
||||
const event = makeEvent({ dateTime: '2026-03-11T18:00:00' })
|
||||
const sections = useEventGrouping([event], NOW)
|
||||
expect(sections[0]!.dateGroups[0]!.showSubheader).toBe(false)
|
||||
})
|
||||
|
||||
it('sets showSubheader=true for non-today sections', () => {
|
||||
const events = [
|
||||
makeEvent({ dateTime: '2026-03-13T10:00:00' }), // thisWeek
|
||||
makeEvent({ dateTime: '2026-03-30T10:00:00' }), // later (beyond next week)
|
||||
makeEvent({ dateTime: '2026-03-01T10:00:00' }), // past
|
||||
]
|
||||
const sections = useEventGrouping(events, NOW)
|
||||
for (const section of sections) {
|
||||
for (const group of section.dateGroups) {
|
||||
expect(group.showSubheader).toBe(true)
|
||||
}
|
||||
}
|
||||
})
|
||||
|
||||
it('sets emphasized=true only for "today" section', () => {
|
||||
const events = [
|
||||
makeEvent({ dateTime: '2026-03-11T18:00:00' }),
|
||||
makeEvent({ dateTime: '2026-03-30T10:00:00' }),
|
||||
]
|
||||
const sections = useEventGrouping(events, NOW)
|
||||
expect(sections[0]!.emphasized).toBe(true) // today
|
||||
expect(sections[1]!.emphasized).toBe(false) // later
|
||||
})
|
||||
|
||||
it('on Sunday, tomorrow (Monday) goes to "nextWeek" not "thisWeek"', () => {
|
||||
// Sunday 2026-03-15
|
||||
const sunday = new Date(2026, 2, 15, 12, 0, 0)
|
||||
const mondayEvent = makeEvent({ title: 'Monday', dateTime: '2026-03-16T10:00:00' })
|
||||
const sections = useEventGrouping([mondayEvent], sunday)
|
||||
expect(sections).toHaveLength(1)
|
||||
expect(sections[0]!.key).toBe('nextWeek')
|
||||
})
|
||||
|
||||
it('on Sunday, today events still appear under "today"', () => {
|
||||
const sunday = new Date(2026, 2, 15, 12, 0, 0)
|
||||
const todayEvent = makeEvent({ dateTime: '2026-03-15T18:00:00' })
|
||||
const sections = useEventGrouping([todayEvent], sunday)
|
||||
expect(sections[0]!.key).toBe('today')
|
||||
})
|
||||
|
||||
it('dateGroup labels are formatted via Intl', () => {
|
||||
const event = makeEvent({ dateTime: '2026-03-13T10:00:00' }) // Friday
|
||||
const sections = useEventGrouping([event], NOW)
|
||||
const label = sections[0]!.dateGroups[0]!.label
|
||||
// The exact format depends on locale, but should contain the day number
|
||||
expect(label).toContain('13')
|
||||
})
|
||||
})
|
||||
@@ -116,4 +116,168 @@ describe('useEventStorage', () => {
|
||||
expect(events).toHaveLength(1)
|
||||
expect(events[0]!.title).toBe('New Title')
|
||||
})
|
||||
|
||||
it('saves and retrieves RSVP for an existing event', () => {
|
||||
const { saveCreatedEvent, saveRsvp, getRsvp } = useEventStorage()
|
||||
|
||||
saveCreatedEvent({
|
||||
eventToken: 'abc-123',
|
||||
title: 'Birthday',
|
||||
dateTime: '2026-06-15T20:00:00+02:00',
|
||||
expiryDate: '2026-07-15',
|
||||
})
|
||||
|
||||
saveRsvp('abc-123', 'rsvp-token-1', 'Max', 'Birthday', '2026-06-15T20:00:00+02:00')
|
||||
|
||||
const rsvp = getRsvp('abc-123')
|
||||
expect(rsvp).toEqual({ rsvpToken: 'rsvp-token-1', rsvpName: 'Max' })
|
||||
})
|
||||
|
||||
it('saves RSVP for a new event (not previously stored)', () => {
|
||||
const { saveRsvp, getRsvp, getStoredEvents } = useEventStorage()
|
||||
|
||||
saveRsvp('new-event', 'rsvp-token-2', 'Anna', 'Party', '2026-08-01T18:00:00+02:00')
|
||||
|
||||
const rsvp = getRsvp('new-event')
|
||||
expect(rsvp).toEqual({ rsvpToken: 'rsvp-token-2', rsvpName: 'Anna' })
|
||||
|
||||
const events = getStoredEvents()
|
||||
expect(events).toHaveLength(1)
|
||||
expect(events[0]!.eventToken).toBe('new-event')
|
||||
expect(events[0]!.title).toBe('Party')
|
||||
})
|
||||
|
||||
it('returns undefined RSVP for event without RSVP', () => {
|
||||
const { saveCreatedEvent, getRsvp } = useEventStorage()
|
||||
|
||||
saveCreatedEvent({
|
||||
eventToken: 'abc-123',
|
||||
title: 'Test',
|
||||
dateTime: '2026-06-15T20:00:00+02:00',
|
||||
expiryDate: '2026-07-15',
|
||||
})
|
||||
|
||||
expect(getRsvp('abc-123')).toBeUndefined()
|
||||
})
|
||||
|
||||
it('returns undefined RSVP for unknown event', () => {
|
||||
const { getRsvp } = useEventStorage()
|
||||
expect(getRsvp('unknown')).toBeUndefined()
|
||||
})
|
||||
|
||||
it('removes an event by token', () => {
|
||||
const { saveCreatedEvent, getStoredEvents, removeEvent } = useEventStorage()
|
||||
|
||||
saveCreatedEvent({
|
||||
eventToken: 'event-1',
|
||||
title: 'First',
|
||||
dateTime: '2026-06-15T20:00:00+02:00',
|
||||
expiryDate: '2026-07-15',
|
||||
})
|
||||
|
||||
saveCreatedEvent({
|
||||
eventToken: 'event-2',
|
||||
title: 'Second',
|
||||
dateTime: '2026-07-15T20:00:00+02:00',
|
||||
expiryDate: '2026-08-15',
|
||||
})
|
||||
|
||||
removeEvent('event-1')
|
||||
|
||||
const events = getStoredEvents()
|
||||
expect(events).toHaveLength(1)
|
||||
expect(events[0]!.eventToken).toBe('event-2')
|
||||
})
|
||||
|
||||
it('removeEvent does nothing for unknown token', () => {
|
||||
const { saveCreatedEvent, getStoredEvents, removeEvent } = useEventStorage()
|
||||
|
||||
saveCreatedEvent({
|
||||
eventToken: 'event-1',
|
||||
title: 'First',
|
||||
dateTime: '2026-06-15T20:00:00+02:00',
|
||||
expiryDate: '2026-07-15',
|
||||
})
|
||||
|
||||
removeEvent('nonexistent')
|
||||
|
||||
expect(getStoredEvents()).toHaveLength(1)
|
||||
})
|
||||
})
|
||||
|
||||
describe('isValidStoredEvent', () => {
|
||||
// Import directly since it's an exported function
|
||||
let isValidStoredEvent: (e: unknown) => boolean
|
||||
|
||||
beforeEach(async () => {
|
||||
const mod = await import('../useEventStorage')
|
||||
isValidStoredEvent = mod.isValidStoredEvent
|
||||
})
|
||||
|
||||
it('returns true for a valid event', () => {
|
||||
expect(
|
||||
isValidStoredEvent({
|
||||
eventToken: 'abc-123',
|
||||
title: 'Birthday',
|
||||
dateTime: '2026-06-15T20:00:00+02:00',
|
||||
expiryDate: '2026-07-15',
|
||||
}),
|
||||
).toBe(true)
|
||||
})
|
||||
|
||||
it('returns false for null', () => {
|
||||
expect(isValidStoredEvent(null)).toBe(false)
|
||||
})
|
||||
|
||||
it('returns false for non-object', () => {
|
||||
expect(isValidStoredEvent('string')).toBe(false)
|
||||
})
|
||||
|
||||
it('returns false when eventToken is missing', () => {
|
||||
expect(
|
||||
isValidStoredEvent({
|
||||
title: 'Birthday',
|
||||
dateTime: '2026-06-15T20:00:00+02:00',
|
||||
}),
|
||||
).toBe(false)
|
||||
})
|
||||
|
||||
it('returns false when eventToken is empty', () => {
|
||||
expect(
|
||||
isValidStoredEvent({
|
||||
eventToken: '',
|
||||
title: 'Birthday',
|
||||
dateTime: '2026-06-15T20:00:00+02:00',
|
||||
}),
|
||||
).toBe(false)
|
||||
})
|
||||
|
||||
it('returns false when title is missing', () => {
|
||||
expect(
|
||||
isValidStoredEvent({
|
||||
eventToken: 'abc-123',
|
||||
dateTime: '2026-06-15T20:00:00+02:00',
|
||||
}),
|
||||
).toBe(false)
|
||||
})
|
||||
|
||||
it('returns false when dateTime is invalid', () => {
|
||||
expect(
|
||||
isValidStoredEvent({
|
||||
eventToken: 'abc-123',
|
||||
title: 'Birthday',
|
||||
dateTime: 'not-a-date',
|
||||
}),
|
||||
).toBe(false)
|
||||
})
|
||||
|
||||
it('returns false when dateTime is empty', () => {
|
||||
expect(
|
||||
isValidStoredEvent({
|
||||
eventToken: 'abc-123',
|
||||
title: 'Birthday',
|
||||
dateTime: '',
|
||||
}),
|
||||
).toBe(false)
|
||||
})
|
||||
})
|
||||
|
||||
72
frontend/src/composables/__tests__/useRelativeTime.spec.ts
Normal file
72
frontend/src/composables/__tests__/useRelativeTime.spec.ts
Normal file
@@ -0,0 +1,72 @@
|
||||
import { describe, it, expect } from 'vitest'
|
||||
import { formatRelativeTime } from '../useRelativeTime'
|
||||
|
||||
describe('formatRelativeTime', () => {
|
||||
const now = new Date('2026-06-15T12:00:00Z')
|
||||
|
||||
it('formats seconds ago', () => {
|
||||
const result = formatRelativeTime('2026-06-15T11:59:30Z', now)
|
||||
expect(result).toMatch(/30 seconds ago/)
|
||||
})
|
||||
|
||||
it('formats minutes ago', () => {
|
||||
const result = formatRelativeTime('2026-06-15T11:55:00Z', now)
|
||||
expect(result).toMatch(/5 minutes ago/)
|
||||
})
|
||||
|
||||
it('formats hours ago', () => {
|
||||
const result = formatRelativeTime('2026-06-15T09:00:00Z', now)
|
||||
expect(result).toMatch(/3 hours ago/)
|
||||
})
|
||||
|
||||
it('formats days ago', () => {
|
||||
const result = formatRelativeTime('2026-06-13T12:00:00Z', now)
|
||||
expect(result).toMatch(/2 days ago/)
|
||||
})
|
||||
|
||||
it('formats weeks ago', () => {
|
||||
const result = formatRelativeTime('2026-06-01T12:00:00Z', now)
|
||||
expect(result).toMatch(/2 weeks ago/)
|
||||
})
|
||||
|
||||
it('formats months ago', () => {
|
||||
const result = formatRelativeTime('2026-03-15T12:00:00Z', now)
|
||||
expect(result).toMatch(/3 months ago/)
|
||||
})
|
||||
|
||||
it('formats years ago', () => {
|
||||
const result = formatRelativeTime('2024-06-15T12:00:00Z', now)
|
||||
expect(result).toMatch(/2 years ago/)
|
||||
})
|
||||
|
||||
it('formats future seconds', () => {
|
||||
const result = formatRelativeTime('2026-06-15T12:00:30Z', now)
|
||||
expect(result).toMatch(/in 30 seconds/)
|
||||
})
|
||||
|
||||
it('formats future days', () => {
|
||||
const result = formatRelativeTime('2026-06-18T12:00:00Z', now)
|
||||
expect(result).toMatch(/in 3 days/)
|
||||
})
|
||||
|
||||
it('formats future months', () => {
|
||||
const result = formatRelativeTime('2026-09-15T12:00:00Z', now)
|
||||
expect(result).toMatch(/in 3 months/)
|
||||
})
|
||||
|
||||
it('formats "now" for zero difference', () => {
|
||||
const result = formatRelativeTime('2026-06-15T12:00:00Z', now)
|
||||
// Intl.RelativeTimeFormat with numeric: 'auto' returns "now" for 0 seconds
|
||||
expect(result).toMatch(/now/)
|
||||
})
|
||||
|
||||
it('formats yesterday', () => {
|
||||
const result = formatRelativeTime('2026-06-14T12:00:00Z', now)
|
||||
expect(result).toMatch(/yesterday|1 day ago/)
|
||||
})
|
||||
|
||||
it('formats tomorrow', () => {
|
||||
const result = formatRelativeTime('2026-06-16T12:00:00Z', now)
|
||||
expect(result).toMatch(/tomorrow|in 1 day/)
|
||||
})
|
||||
})
|
||||
149
frontend/src/composables/useEventGrouping.ts
Normal file
149
frontend/src/composables/useEventGrouping.ts
Normal file
@@ -0,0 +1,149 @@
|
||||
import type { StoredEvent } from './useEventStorage'
|
||||
|
||||
export type SectionKey = 'today' | 'thisWeek' | 'nextWeek' | 'later' | 'past'
|
||||
|
||||
export interface DateGroup {
|
||||
dateKey: string
|
||||
label: string
|
||||
events: StoredEvent[]
|
||||
showSubheader: boolean
|
||||
}
|
||||
|
||||
export interface EventSection {
|
||||
key: SectionKey
|
||||
label: string
|
||||
dateGroups: DateGroup[]
|
||||
emphasized: boolean
|
||||
}
|
||||
|
||||
const SECTION_ORDER: SectionKey[] = ['today', 'thisWeek', 'nextWeek', 'later', 'past']
|
||||
|
||||
const SECTION_LABELS: Record<SectionKey, string> = {
|
||||
today: 'Today',
|
||||
thisWeek: 'This Week',
|
||||
nextWeek: 'Next Week',
|
||||
later: 'Later',
|
||||
past: 'Past',
|
||||
}
|
||||
|
||||
function startOfDay(date: Date): Date {
|
||||
const d = new Date(date)
|
||||
d.setHours(0, 0, 0, 0)
|
||||
return d
|
||||
}
|
||||
|
||||
function endOfDay(date: Date): Date {
|
||||
const d = new Date(date)
|
||||
d.setHours(23, 59, 59, 999)
|
||||
return d
|
||||
}
|
||||
|
||||
function endOfWeek(date: Date): Date {
|
||||
const d = new Date(date)
|
||||
const dayOfWeek = d.getDay() // 0=Sun, 1=Mon, ..., 6=Sat
|
||||
// ISO week: Monday is first day. End of week = Sunday.
|
||||
// If today is Sunday (0), end of week is today.
|
||||
// Otherwise, days until Sunday = 7 - dayOfWeek
|
||||
const daysUntilSunday = dayOfWeek === 0 ? 0 : 7 - dayOfWeek
|
||||
d.setDate(d.getDate() + daysUntilSunday)
|
||||
return endOfDay(d)
|
||||
}
|
||||
|
||||
function endOfNextWeek(date: Date): Date {
|
||||
const thisWeekEnd = endOfWeek(date)
|
||||
const d = new Date(thisWeekEnd)
|
||||
d.setDate(d.getDate() + 7)
|
||||
return endOfDay(d)
|
||||
}
|
||||
|
||||
function toDateKey(date: Date): string {
|
||||
const y = date.getFullYear()
|
||||
const m = String(date.getMonth() + 1).padStart(2, '0')
|
||||
const d = String(date.getDate()).padStart(2, '0')
|
||||
return `${y}-${m}-${d}`
|
||||
}
|
||||
|
||||
function formatDateLabel(date: Date): string {
|
||||
return new Intl.DateTimeFormat(undefined, {
|
||||
weekday: 'short',
|
||||
day: 'numeric',
|
||||
month: 'short',
|
||||
}).format(date)
|
||||
}
|
||||
|
||||
function classifyEvent(eventDate: Date, todayStart: Date, todayEnd: Date, weekEnd: Date, nextWeekEnd: Date): SectionKey {
|
||||
if (eventDate < todayStart) return 'past'
|
||||
if (eventDate <= todayEnd) return 'today'
|
||||
if (eventDate <= weekEnd) return 'thisWeek'
|
||||
if (eventDate <= nextWeekEnd) return 'nextWeek'
|
||||
return 'later'
|
||||
}
|
||||
|
||||
export function useEventGrouping(events: StoredEvent[], now: Date = new Date()): EventSection[] {
|
||||
const todayStart = startOfDay(now)
|
||||
const todayEnd = endOfDay(now)
|
||||
const weekEnd = endOfWeek(now)
|
||||
const nextWeekEnd = endOfNextWeek(now)
|
||||
|
||||
// Classify events into sections
|
||||
const buckets: Record<SectionKey, StoredEvent[]> = {
|
||||
today: [],
|
||||
thisWeek: [],
|
||||
nextWeek: [],
|
||||
later: [],
|
||||
past: [],
|
||||
}
|
||||
|
||||
for (const event of events) {
|
||||
const eventDate = new Date(event.dateTime)
|
||||
const section = classifyEvent(eventDate, todayStart, todayEnd, weekEnd, nextWeekEnd)
|
||||
buckets[section].push(event)
|
||||
}
|
||||
|
||||
// Build sections
|
||||
const sections: EventSection[] = []
|
||||
|
||||
for (const key of SECTION_ORDER) {
|
||||
const sectionEvents = buckets[key]
|
||||
if (sectionEvents.length === 0) continue
|
||||
|
||||
// Sort events
|
||||
const ascending = key !== 'past'
|
||||
sectionEvents.sort((a, b) => {
|
||||
const diff = new Date(a.dateTime).getTime() - new Date(b.dateTime).getTime()
|
||||
return ascending ? diff : -diff
|
||||
})
|
||||
|
||||
// Group by date
|
||||
const dateGroupMap = new Map<string, StoredEvent[]>()
|
||||
for (const event of sectionEvents) {
|
||||
const dateKey = toDateKey(new Date(event.dateTime))
|
||||
const group = dateGroupMap.get(dateKey)
|
||||
if (group) {
|
||||
group.push(event)
|
||||
} else {
|
||||
dateGroupMap.set(dateKey, [event])
|
||||
}
|
||||
}
|
||||
|
||||
// Convert to DateGroup array (order preserved from sorted events)
|
||||
const dateGroups: DateGroup[] = []
|
||||
for (const [dateKey, groupEvents] of dateGroupMap) {
|
||||
dateGroups.push({
|
||||
dateKey,
|
||||
label: formatDateLabel(new Date(groupEvents[0]!.dateTime)),
|
||||
events: groupEvents,
|
||||
showSubheader: key !== 'today',
|
||||
})
|
||||
}
|
||||
|
||||
sections.push({
|
||||
key,
|
||||
label: SECTION_LABELS[key],
|
||||
dateGroups,
|
||||
emphasized: key === 'today',
|
||||
})
|
||||
}
|
||||
|
||||
return sections
|
||||
}
|
||||
@@ -4,10 +4,30 @@ export interface StoredEvent {
|
||||
title: string
|
||||
dateTime: string
|
||||
expiryDate: string
|
||||
rsvpToken?: string
|
||||
rsvpName?: string
|
||||
}
|
||||
|
||||
import { ref } from 'vue'
|
||||
|
||||
const STORAGE_KEY = 'fete:events'
|
||||
|
||||
const version = ref(0)
|
||||
|
||||
export function isValidStoredEvent(e: unknown): e is StoredEvent {
|
||||
if (typeof e !== 'object' || e === null) return false
|
||||
const obj = e as Record<string, unknown>
|
||||
return (
|
||||
typeof obj.eventToken === 'string' &&
|
||||
obj.eventToken.length > 0 &&
|
||||
typeof obj.title === 'string' &&
|
||||
obj.title.length > 0 &&
|
||||
typeof obj.dateTime === 'string' &&
|
||||
obj.dateTime.length > 0 &&
|
||||
!isNaN(new Date(obj.dateTime).getTime())
|
||||
)
|
||||
}
|
||||
|
||||
function readEvents(): StoredEvent[] {
|
||||
try {
|
||||
const raw = localStorage.getItem(STORAGE_KEY)
|
||||
@@ -19,6 +39,7 @@ function readEvents(): StoredEvent[] {
|
||||
|
||||
function writeEvents(events: StoredEvent[]): void {
|
||||
localStorage.setItem(STORAGE_KEY, JSON.stringify(events))
|
||||
version.value++
|
||||
}
|
||||
|
||||
export function useEventStorage() {
|
||||
@@ -29,6 +50,7 @@ export function useEventStorage() {
|
||||
}
|
||||
|
||||
function getStoredEvents(): StoredEvent[] {
|
||||
void version.value
|
||||
return readEvents()
|
||||
}
|
||||
|
||||
@@ -37,5 +59,30 @@ export function useEventStorage() {
|
||||
return event?.organizerToken
|
||||
}
|
||||
|
||||
return { saveCreatedEvent, getStoredEvents, getOrganizerToken }
|
||||
function saveRsvp(eventToken: string, rsvpToken: string, rsvpName: string, title: string, dateTime: string): void {
|
||||
const events = readEvents()
|
||||
const existing = events.find((e) => e.eventToken === eventToken)
|
||||
if (existing) {
|
||||
existing.rsvpToken = rsvpToken
|
||||
existing.rsvpName = rsvpName
|
||||
} else {
|
||||
events.push({ eventToken, title, dateTime, expiryDate: '', rsvpToken, rsvpName })
|
||||
}
|
||||
writeEvents(events)
|
||||
}
|
||||
|
||||
function getRsvp(eventToken: string): { rsvpToken: string; rsvpName: string } | undefined {
|
||||
const event = readEvents().find((e) => e.eventToken === eventToken)
|
||||
if (event?.rsvpToken && event?.rsvpName) {
|
||||
return { rsvpToken: event.rsvpToken, rsvpName: event.rsvpName }
|
||||
}
|
||||
return undefined
|
||||
}
|
||||
|
||||
function removeEvent(eventToken: string): void {
|
||||
const events = readEvents().filter((e) => e.eventToken !== eventToken)
|
||||
writeEvents(events)
|
||||
}
|
||||
|
||||
return { saveCreatedEvent, getStoredEvents, getOrganizerToken, saveRsvp, getRsvp, removeEvent }
|
||||
}
|
||||
|
||||
23
frontend/src/composables/useRelativeTime.ts
Normal file
23
frontend/src/composables/useRelativeTime.ts
Normal file
@@ -0,0 +1,23 @@
|
||||
const UNITS: [Intl.RelativeTimeFormatUnit, number][] = [
|
||||
['year', 365 * 24 * 60 * 60],
|
||||
['month', 30 * 24 * 60 * 60],
|
||||
['week', 7 * 24 * 60 * 60],
|
||||
['day', 24 * 60 * 60],
|
||||
['hour', 60 * 60],
|
||||
['minute', 60],
|
||||
['second', 1],
|
||||
]
|
||||
|
||||
export function formatRelativeTime(dateTime: string, now: Date = new Date()): string {
|
||||
const target = new Date(dateTime)
|
||||
const diffSeconds = Math.round((target.getTime() - now.getTime()) / 1000)
|
||||
|
||||
for (const [unit, secondsInUnit] of UNITS) {
|
||||
if (Math.abs(diffSeconds) >= secondsInUnit) {
|
||||
const value = Math.round(diffSeconds / secondsInUnit)
|
||||
return new Intl.RelativeTimeFormat(undefined, { numeric: 'auto' }).format(value, unit)
|
||||
}
|
||||
}
|
||||
|
||||
return new Intl.RelativeTimeFormat(undefined, { numeric: 'auto' }).format(0, 'second')
|
||||
}
|
||||
@@ -15,7 +15,7 @@ const router = createRouter({
|
||||
component: () => import('../views/EventCreateView.vue'),
|
||||
},
|
||||
{
|
||||
path: '/events/:token',
|
||||
path: '/events/:eventToken',
|
||||
name: 'event',
|
||||
component: () => import('../views/EventDetailView.vue'),
|
||||
},
|
||||
|
||||
@@ -215,7 +215,7 @@ async function handleSubmit() {
|
||||
expiryDate: data.expiryDate,
|
||||
})
|
||||
|
||||
router.push({ name: 'event', params: { token: data.eventToken } })
|
||||
router.push({ name: 'event', params: { eventToken: data.eventToken } })
|
||||
}
|
||||
} catch {
|
||||
submitting.value = false
|
||||
|
||||
@@ -1,12 +1,22 @@
|
||||
<template>
|
||||
<main class="detail">
|
||||
<!-- Hero image with overlaid header -->
|
||||
<div class="detail__hero">
|
||||
<img
|
||||
class="detail__hero-img"
|
||||
src="@/assets/images/event-hero-placeholder.jpg"
|
||||
alt=""
|
||||
/>
|
||||
<div class="detail__hero-overlay" />
|
||||
<header class="detail__header">
|
||||
<RouterLink to="/" class="detail__back" aria-label="Back to home">←</RouterLink>
|
||||
<span class="detail__brand">fete</span>
|
||||
</header>
|
||||
</div>
|
||||
|
||||
<div class="detail__body">
|
||||
<!-- Loading state -->
|
||||
<div v-if="state === 'loading'" class="detail__card" aria-busy="true" aria-label="Loading event details">
|
||||
<div v-if="state === 'loading'" class="detail__content" aria-busy="true" aria-label="Loading event details">
|
||||
<div class="skeleton skeleton--title" />
|
||||
<div class="skeleton skeleton--line" />
|
||||
<div class="skeleton skeleton--line skeleton--short" />
|
||||
@@ -14,46 +24,85 @@
|
||||
</div>
|
||||
|
||||
<!-- Loaded state -->
|
||||
<div v-else-if="state === 'loaded' && event" class="detail__card">
|
||||
<div v-else-if="state === 'loaded' && event" class="detail__content">
|
||||
<div v-if="event.expired" class="detail__banner detail__banner--expired" role="status">
|
||||
This event has ended.
|
||||
</div>
|
||||
|
||||
<h1 class="detail__title">{{ event.title }}</h1>
|
||||
|
||||
<dl class="detail__fields">
|
||||
<div class="detail__field">
|
||||
<dt class="detail__label">Date & Time</dt>
|
||||
<dd class="detail__value">{{ formattedDateTime }}</dd>
|
||||
<dl class="detail__meta">
|
||||
<div class="detail__meta-item">
|
||||
<dt class="detail__meta-icon" aria-label="Date and time">
|
||||
<svg width="18" height="18" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" aria-hidden="true"><rect x="3" y="4" width="18" height="18" rx="2"/><line x1="16" y1="2" x2="16" y2="6"/><line x1="8" y1="2" x2="8" y2="6"/><line x1="3" y1="10" x2="21" y2="10"/></svg>
|
||||
</dt>
|
||||
<dd class="detail__meta-text">{{ formattedDateTime }}</dd>
|
||||
</div>
|
||||
|
||||
<div v-if="event.description" class="detail__field">
|
||||
<dt class="detail__label">Description</dt>
|
||||
<dd class="detail__value">{{ event.description }}</dd>
|
||||
<div v-if="event.location" class="detail__meta-item">
|
||||
<dt class="detail__meta-icon" aria-label="Location">
|
||||
<svg width="18" height="18" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" aria-hidden="true"><path d="M21 10c0 7-9 13-9 13s-9-6-9-13a9 9 0 0 1 18 0z"/><circle cx="12" cy="10" r="3"/></svg>
|
||||
</dt>
|
||||
<dd class="detail__meta-text">{{ event.location }}</dd>
|
||||
</div>
|
||||
|
||||
<div v-if="event.location" class="detail__field">
|
||||
<dt class="detail__label">Location</dt>
|
||||
<dd class="detail__value">{{ event.location }}</dd>
|
||||
</div>
|
||||
|
||||
<div class="detail__field">
|
||||
<dt class="detail__label">Attendees</dt>
|
||||
<dd class="detail__value">{{ event.attendeeCount }}</dd>
|
||||
<div class="detail__meta-item">
|
||||
<dt class="detail__meta-icon" aria-label="Attendees">
|
||||
<svg width="18" height="18" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" aria-hidden="true"><path d="M17 21v-2a4 4 0 0 0-4-4H5a4 4 0 0 0-4 4v2"/><circle cx="9" cy="7" r="4"/><path d="M23 21v-2a4 4 0 0 0-3-3.87"/><path d="M16 3.13a4 4 0 0 1 0 7.75"/></svg>
|
||||
</dt>
|
||||
<dd class="detail__meta-text">{{ event.attendeeCount }} going</dd>
|
||||
</div>
|
||||
</dl>
|
||||
|
||||
<div v-if="event.expired" class="detail__banner detail__banner--expired" role="status">
|
||||
This event has ended.
|
||||
<div v-if="event.description" class="detail__section">
|
||||
<h2 class="detail__section-title">About</h2>
|
||||
<p class="detail__description">{{ event.description }}</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!-- Not found state -->
|
||||
<div v-else-if="state === 'not-found'" class="detail__card detail__card--center" role="status">
|
||||
<div v-else-if="state === 'not-found'" class="detail__content detail__content--center" role="status">
|
||||
<p class="detail__message">Event not found.</p>
|
||||
</div>
|
||||
|
||||
<!-- Error state -->
|
||||
<div v-else-if="state === 'error'" class="detail__card detail__card--center" role="alert">
|
||||
<div v-else-if="state === 'error'" class="detail__content detail__content--center" role="alert">
|
||||
<p class="detail__message">Something went wrong.</p>
|
||||
<button class="btn-primary" type="button" @click="fetchEvent">Retry</button>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!-- RSVP bar (only for loaded, non-expired events) -->
|
||||
<RsvpBar
|
||||
v-if="state === 'loaded' && event && !event.expired && !isOrganizer"
|
||||
:has-rsvp="!!rsvpName"
|
||||
@open="sheetOpen = true"
|
||||
/>
|
||||
|
||||
<!-- RSVP bottom sheet -->
|
||||
<BottomSheet :open="sheetOpen" label="RSVP" @close="sheetOpen = false">
|
||||
<h2 class="sheet-title">RSVP</h2>
|
||||
<form class="rsvp-form" @submit.prevent="submitRsvp" novalidate>
|
||||
<div class="form-group">
|
||||
<label class="rsvp-form__label" for="rsvp-name">Your name</label>
|
||||
<input
|
||||
id="rsvp-name"
|
||||
v-model.trim="nameInput"
|
||||
class="form-field"
|
||||
type="text"
|
||||
placeholder="e.g. Max Mustermann"
|
||||
maxlength="100"
|
||||
required
|
||||
@input="nameError = ''"
|
||||
/>
|
||||
<span v-if="nameError" class="rsvp-form__field-error" role="alert">{{ nameError }}</span>
|
||||
</div>
|
||||
<button class="btn-primary" type="submit" :disabled="submitting">
|
||||
{{ submitting ? 'Sending…' : "Count me in" }}
|
||||
</button>
|
||||
<p v-if="submitError" class="rsvp-form__field-error rsvp-form__error" role="alert">{{ submitError }}</p>
|
||||
</form>
|
||||
</BottomSheet>
|
||||
</main>
|
||||
</template>
|
||||
|
||||
@@ -61,15 +110,29 @@
|
||||
import { ref, computed, onMounted } from 'vue'
|
||||
import { RouterLink, useRoute } from 'vue-router'
|
||||
import { api } from '@/api/client'
|
||||
import { useEventStorage } from '@/composables/useEventStorage'
|
||||
import BottomSheet from '@/components/BottomSheet.vue'
|
||||
import RsvpBar from '@/components/RsvpBar.vue'
|
||||
import type { components } from '@/api/schema'
|
||||
|
||||
type GetEventResponse = components['schemas']['GetEventResponse']
|
||||
type State = 'loading' | 'loaded' | 'not-found' | 'error'
|
||||
|
||||
const route = useRoute()
|
||||
const { saveRsvp, getRsvp, getOrganizerToken } = useEventStorage()
|
||||
|
||||
const state = ref<State>('loading')
|
||||
const event = ref<GetEventResponse | null>(null)
|
||||
|
||||
// RSVP state
|
||||
const sheetOpen = ref(false)
|
||||
const nameInput = ref('')
|
||||
const nameError = ref('')
|
||||
const submitError = ref('')
|
||||
const submitting = ref(false)
|
||||
const rsvpName = ref<string | undefined>(undefined)
|
||||
const isOrganizer = ref(false)
|
||||
|
||||
const formattedDateTime = computed(() => {
|
||||
if (!event.value) return ''
|
||||
const formatted = new Intl.DateTimeFormat(undefined, {
|
||||
@@ -85,7 +148,7 @@ async function fetchEvent() {
|
||||
|
||||
try {
|
||||
const { data, error, response } = await api.GET('/events/{token}', {
|
||||
params: { path: { token: route.params.token as string } },
|
||||
params: { path: { token: route.params.eventToken as string } },
|
||||
})
|
||||
|
||||
if (error) {
|
||||
@@ -95,11 +158,68 @@ async function fetchEvent() {
|
||||
|
||||
event.value = data!
|
||||
state.value = 'loaded'
|
||||
|
||||
// Check if current user is the organizer
|
||||
isOrganizer.value = !!getOrganizerToken(event.value.eventToken)
|
||||
|
||||
// Restore RSVP status from localStorage
|
||||
const stored = getRsvp(event.value.eventToken)
|
||||
if (stored) {
|
||||
rsvpName.value = stored.rsvpName
|
||||
}
|
||||
} catch {
|
||||
state.value = 'error'
|
||||
}
|
||||
}
|
||||
|
||||
async function submitRsvp() {
|
||||
nameError.value = ''
|
||||
submitError.value = ''
|
||||
|
||||
if (!nameInput.value) {
|
||||
nameError.value = 'Please enter your name.'
|
||||
return
|
||||
}
|
||||
|
||||
if (nameInput.value.length > 100) {
|
||||
nameError.value = 'Name must be 100 characters or fewer.'
|
||||
return
|
||||
}
|
||||
|
||||
submitting.value = true
|
||||
|
||||
try {
|
||||
const { data, error } = await api.POST('/events/{token}/rsvps', {
|
||||
params: { path: { token: route.params.eventToken as string } },
|
||||
body: { name: nameInput.value },
|
||||
})
|
||||
|
||||
if (error) {
|
||||
submitError.value = 'Could not submit RSVP. Please try again.'
|
||||
return
|
||||
}
|
||||
|
||||
// Persist RSVP in localStorage
|
||||
saveRsvp(
|
||||
event.value!.eventToken,
|
||||
data!.rsvpToken,
|
||||
data!.name,
|
||||
event.value!.title,
|
||||
event.value!.dateTime,
|
||||
)
|
||||
|
||||
// Update UI
|
||||
rsvpName.value = data!.name
|
||||
event.value!.attendeeCount += 1
|
||||
sheetOpen.value = false
|
||||
nameInput.value = ''
|
||||
} catch {
|
||||
submitError.value = 'Could not submit RSVP. Please try again.'
|
||||
} finally {
|
||||
submitting.value = false
|
||||
}
|
||||
}
|
||||
|
||||
onMounted(fetchEvent)
|
||||
</script>
|
||||
|
||||
@@ -107,14 +227,53 @@ onMounted(fetchEvent)
|
||||
.detail {
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: var(--spacing-2xl);
|
||||
padding-top: var(--spacing-lg);
|
||||
/* Break out of .app-container constraints */
|
||||
width: 100dvw;
|
||||
flex: 1;
|
||||
position: relative;
|
||||
left: 50%;
|
||||
transform: translateX(-50%);
|
||||
margin: calc(-1 * var(--content-padding)) 0;
|
||||
overflow-x: hidden;
|
||||
}
|
||||
|
||||
/* Hero image section */
|
||||
.detail__hero {
|
||||
position: relative;
|
||||
width: 100%;
|
||||
height: 260px;
|
||||
overflow: hidden;
|
||||
flex-shrink: 0;
|
||||
}
|
||||
|
||||
.detail__hero-img {
|
||||
width: 100%;
|
||||
height: 100%;
|
||||
object-fit: cover;
|
||||
}
|
||||
|
||||
.detail__hero-overlay {
|
||||
position: absolute;
|
||||
inset: 0;
|
||||
background: linear-gradient(
|
||||
to bottom,
|
||||
rgba(0, 0, 0, 0.4) 0%,
|
||||
transparent 50%,
|
||||
var(--color-gradient-start) 100%
|
||||
);
|
||||
}
|
||||
|
||||
.detail__header {
|
||||
position: absolute;
|
||||
top: 0;
|
||||
left: 0;
|
||||
right: 0;
|
||||
display: flex;
|
||||
align-items: center;
|
||||
gap: var(--spacing-sm);
|
||||
padding: var(--spacing-lg) var(--content-padding);
|
||||
padding-top: env(safe-area-inset-top, var(--spacing-lg));
|
||||
z-index: 1;
|
||||
}
|
||||
|
||||
.detail__back {
|
||||
@@ -130,85 +289,130 @@ onMounted(fetchEvent)
|
||||
color: var(--color-text-on-gradient);
|
||||
}
|
||||
|
||||
.detail__card {
|
||||
background: var(--color-card);
|
||||
border-radius: var(--radius-card);
|
||||
padding: var(--spacing-xl);
|
||||
box-shadow: var(--shadow-card);
|
||||
.detail__body {
|
||||
flex: 1;
|
||||
padding: var(--spacing-lg) var(--content-padding);
|
||||
padding-bottom: 6rem;
|
||||
}
|
||||
|
||||
.detail__content {
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: var(--spacing-lg);
|
||||
gap: var(--spacing-2xl);
|
||||
max-width: var(--content-max-width);
|
||||
margin: 0 auto;
|
||||
}
|
||||
|
||||
.detail__card--center {
|
||||
.detail__content--center {
|
||||
align-items: center;
|
||||
text-align: center;
|
||||
padding-top: 4rem;
|
||||
}
|
||||
|
||||
/* Title */
|
||||
.detail__title {
|
||||
font-size: 1.4rem;
|
||||
font-weight: 700;
|
||||
color: var(--color-text);
|
||||
font-size: 2rem;
|
||||
font-weight: 800;
|
||||
color: var(--color-text-on-gradient);
|
||||
word-break: break-word;
|
||||
line-height: 1.2;
|
||||
letter-spacing: -0.02em;
|
||||
}
|
||||
|
||||
.detail__fields {
|
||||
/* Meta rows: icon + text */
|
||||
.detail__meta {
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: var(--spacing-md);
|
||||
}
|
||||
|
||||
.detail__field {
|
||||
.detail__meta-item {
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: 0.15rem;
|
||||
align-items: center;
|
||||
gap: var(--spacing-sm);
|
||||
}
|
||||
|
||||
.detail__label {
|
||||
font-size: 0.8rem;
|
||||
font-weight: 700;
|
||||
color: #888;
|
||||
text-transform: uppercase;
|
||||
letter-spacing: 0.04em;
|
||||
.detail__meta-icon {
|
||||
flex-shrink: 0;
|
||||
width: 36px;
|
||||
height: 36px;
|
||||
display: flex;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
background: rgba(255, 255, 255, 0.15);
|
||||
border-radius: 10px;
|
||||
color: var(--color-text-on-gradient);
|
||||
}
|
||||
|
||||
.detail__value {
|
||||
font-size: 0.95rem;
|
||||
color: var(--color-text);
|
||||
.detail__meta-text {
|
||||
font-size: 0.9rem;
|
||||
color: var(--color-text-on-gradient);
|
||||
word-break: break-word;
|
||||
}
|
||||
|
||||
/* About section */
|
||||
.detail__section {
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: var(--spacing-xs);
|
||||
}
|
||||
|
||||
.detail__section-title {
|
||||
font-size: 0.75rem;
|
||||
font-weight: 700;
|
||||
color: rgba(255, 255, 255, 0.5);
|
||||
text-transform: uppercase;
|
||||
letter-spacing: 0.08em;
|
||||
}
|
||||
|
||||
.detail__description {
|
||||
font-size: 0.95rem;
|
||||
color: rgba(255, 255, 255, 0.85);
|
||||
line-height: 1.6;
|
||||
word-break: break-word;
|
||||
}
|
||||
|
||||
/* Expired banner */
|
||||
.detail__banner {
|
||||
padding: var(--spacing-sm) var(--spacing-md);
|
||||
border-radius: var(--radius-card);
|
||||
border-radius: 10px;
|
||||
font-weight: 600;
|
||||
font-size: 0.9rem;
|
||||
font-size: 0.85rem;
|
||||
text-align: center;
|
||||
}
|
||||
|
||||
.detail__banner--expired {
|
||||
background: #fff3e0;
|
||||
color: #e65100;
|
||||
background: rgba(255, 255, 255, 0.12);
|
||||
color: rgba(255, 255, 255, 0.8);
|
||||
backdrop-filter: blur(4px);
|
||||
}
|
||||
|
||||
/* Error / not-found message */
|
||||
.detail__message {
|
||||
font-size: 1rem;
|
||||
font-size: 1.1rem;
|
||||
font-weight: 600;
|
||||
color: var(--color-text);
|
||||
color: var(--color-text-on-gradient);
|
||||
}
|
||||
|
||||
/* Skeleton – shimmer on gradient */
|
||||
.skeleton {
|
||||
background: linear-gradient(90deg, rgba(255, 255, 255, 0.1) 25%, rgba(255, 255, 255, 0.25) 50%, rgba(255, 255, 255, 0.1) 75%);
|
||||
background-size: 200% 100%;
|
||||
}
|
||||
|
||||
/* Skeleton sizes */
|
||||
.skeleton--title {
|
||||
height: 1.6rem;
|
||||
width: 60%;
|
||||
height: 2rem;
|
||||
width: 70%;
|
||||
border-radius: 8px;
|
||||
}
|
||||
|
||||
.skeleton--line {
|
||||
height: 1rem;
|
||||
width: 80%;
|
||||
width: 85%;
|
||||
border-radius: 6px;
|
||||
}
|
||||
|
||||
.skeleton--short {
|
||||
width: 40%;
|
||||
width: 45%;
|
||||
}
|
||||
</style>
|
||||
|
||||
@@ -27,7 +27,7 @@ const route = useRoute()
|
||||
const copyState = ref<'idle' | 'copied' | 'failed'>('idle')
|
||||
|
||||
const eventUrl = computed(() => {
|
||||
return window.location.origin + '/events/' + route.params.token
|
||||
return window.location.origin + '/events/' + route.params.eventToken
|
||||
})
|
||||
|
||||
const copyLabel = computed(() => {
|
||||
|
||||
@@ -1,13 +1,26 @@
|
||||
<template>
|
||||
<main class="home">
|
||||
<h1 class="home__title">fete</h1>
|
||||
<p class="home__subtitle">No events yet.<br />Create your first one!</p>
|
||||
<RouterLink to="/create" class="btn-primary home__cta">+ Create Event</RouterLink>
|
||||
<template v-if="events.length > 0">
|
||||
<EventList />
|
||||
<CreateEventFab />
|
||||
</template>
|
||||
<template v-else>
|
||||
<EmptyState />
|
||||
</template>
|
||||
</main>
|
||||
</template>
|
||||
|
||||
<script setup lang="ts">
|
||||
import { RouterLink } from 'vue-router'
|
||||
import { computed } from 'vue'
|
||||
import { useEventStorage, isValidStoredEvent } from '../composables/useEventStorage'
|
||||
import EventList from '../components/EventList.vue'
|
||||
import EmptyState from '../components/EmptyState.vue'
|
||||
import CreateEventFab from '../components/CreateEventFab.vue'
|
||||
|
||||
const { getStoredEvents } = useEventStorage()
|
||||
|
||||
const events = computed(() => getStoredEvents().filter(isValidStoredEvent))
|
||||
</script>
|
||||
|
||||
<style scoped>
|
||||
@@ -15,27 +28,15 @@ import { RouterLink } from 'vue-router'
|
||||
flex: 1;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
gap: var(--spacing-lg);
|
||||
text-align: center;
|
||||
padding-top: var(--spacing-lg);
|
||||
}
|
||||
|
||||
.home__title {
|
||||
font-size: 2rem;
|
||||
font-weight: 800;
|
||||
color: var(--color-text-on-gradient);
|
||||
text-align: center;
|
||||
}
|
||||
|
||||
.home__subtitle {
|
||||
font-size: 1rem;
|
||||
font-weight: 400;
|
||||
color: var(--color-text-on-gradient);
|
||||
opacity: 0.9;
|
||||
}
|
||||
|
||||
.home__cta {
|
||||
margin-top: var(--spacing-md);
|
||||
max-width: 280px;
|
||||
}
|
||||
</style>
|
||||
|
||||
@@ -14,6 +14,8 @@ vi.mock('@/composables/useEventStorage', () => ({
|
||||
saveCreatedEvent: vi.fn(),
|
||||
getStoredEvents: vi.fn(() => []),
|
||||
getOrganizerToken: vi.fn(),
|
||||
saveRsvp: vi.fn(),
|
||||
getRsvp: vi.fn(),
|
||||
})),
|
||||
}))
|
||||
|
||||
@@ -23,7 +25,7 @@ function createTestRouter() {
|
||||
routes: [
|
||||
{ path: '/', name: 'home', component: { template: '<div />' } },
|
||||
{ path: '/create', name: 'create-event', component: EventCreateView },
|
||||
{ path: '/events/:token', name: 'event', component: { template: '<div />' } },
|
||||
{ path: '/events/:eventToken', name: 'event', component: { template: '<div />' } },
|
||||
],
|
||||
})
|
||||
}
|
||||
@@ -165,6 +167,9 @@ describe('EventCreateView', () => {
|
||||
saveCreatedEvent: mockSave,
|
||||
getStoredEvents: vi.fn(() => []),
|
||||
getOrganizerToken: vi.fn(),
|
||||
saveRsvp: vi.fn(),
|
||||
getRsvp: vi.fn(),
|
||||
removeEvent: vi.fn(),
|
||||
})
|
||||
|
||||
vi.mocked(api.POST).mockResolvedValueOnce({
|
||||
@@ -217,7 +222,7 @@ describe('EventCreateView', () => {
|
||||
|
||||
expect(pushSpy).toHaveBeenCalledWith({
|
||||
name: 'event',
|
||||
params: { token: 'abc-123' },
|
||||
params: { eventToken: 'abc-123' },
|
||||
})
|
||||
})
|
||||
|
||||
|
||||
@@ -7,15 +7,31 @@ import { api } from '@/api/client'
|
||||
vi.mock('@/api/client', () => ({
|
||||
api: {
|
||||
GET: vi.fn(),
|
||||
POST: vi.fn(),
|
||||
},
|
||||
}))
|
||||
|
||||
const mockSaveRsvp = vi.fn()
|
||||
const mockGetRsvp = vi.fn()
|
||||
const mockGetOrganizerToken = vi.fn()
|
||||
|
||||
vi.mock('@/composables/useEventStorage', () => ({
|
||||
useEventStorage: vi.fn(() => ({
|
||||
saveCreatedEvent: vi.fn(),
|
||||
getStoredEvents: vi.fn(() => []),
|
||||
getOrganizerToken: mockGetOrganizerToken,
|
||||
saveRsvp: mockSaveRsvp,
|
||||
getRsvp: mockGetRsvp,
|
||||
removeEvent: vi.fn(),
|
||||
})),
|
||||
}))
|
||||
|
||||
function createTestRouter(_token?: string) {
|
||||
return createRouter({
|
||||
history: createMemoryHistory(),
|
||||
routes: [
|
||||
{ path: '/', name: 'home', component: { template: '<div />' } },
|
||||
{ path: '/events/:token', name: 'event', component: EventDetailView },
|
||||
{ path: '/events/:eventToken', name: 'event', component: EventDetailView },
|
||||
],
|
||||
})
|
||||
}
|
||||
@@ -26,6 +42,7 @@ async function mountWithToken(token = 'test-token') {
|
||||
await router.isReady()
|
||||
return mount(EventDetailView, {
|
||||
global: { plugins: [router] },
|
||||
attachTo: document.body,
|
||||
})
|
||||
}
|
||||
|
||||
@@ -40,12 +57,22 @@ const fullEvent = {
|
||||
expired: false,
|
||||
}
|
||||
|
||||
function mockLoadedEvent(eventOverrides = {}) {
|
||||
vi.mocked(api.GET).mockResolvedValue({
|
||||
data: { ...fullEvent, ...eventOverrides },
|
||||
error: undefined,
|
||||
response: new Response(null, { status: 200 }),
|
||||
} as never)
|
||||
}
|
||||
|
||||
beforeEach(() => {
|
||||
vi.restoreAllMocks()
|
||||
mockGetRsvp.mockReturnValue(undefined)
|
||||
mockGetOrganizerToken.mockReturnValue(undefined)
|
||||
})
|
||||
|
||||
describe('EventDetailView', () => {
|
||||
// T014: Loading state
|
||||
// Loading state
|
||||
it('renders skeleton shimmer placeholders while loading', async () => {
|
||||
vi.mocked(api.GET).mockReturnValue(new Promise(() => {}))
|
||||
|
||||
@@ -53,15 +80,12 @@ describe('EventDetailView', () => {
|
||||
|
||||
expect(wrapper.find('[aria-busy="true"]').exists()).toBe(true)
|
||||
expect(wrapper.findAll('.skeleton').length).toBeGreaterThanOrEqual(3)
|
||||
wrapper.unmount()
|
||||
})
|
||||
|
||||
// T013: Loaded state — all fields
|
||||
// Loaded state — all fields
|
||||
it('renders all event fields when loaded', async () => {
|
||||
vi.mocked(api.GET).mockResolvedValue({
|
||||
data: fullEvent,
|
||||
error: undefined,
|
||||
response: new Response(null, { status: 200 }),
|
||||
} as never)
|
||||
mockLoadedEvent()
|
||||
|
||||
const wrapper = await mountWithToken()
|
||||
await flushPromises()
|
||||
@@ -71,37 +95,25 @@ describe('EventDetailView', () => {
|
||||
expect(wrapper.text()).toContain('Central Park, NYC')
|
||||
expect(wrapper.text()).toContain('12')
|
||||
expect(wrapper.text()).toContain('Europe/Berlin')
|
||||
wrapper.unmount()
|
||||
})
|
||||
|
||||
// T013: Loaded state — locale-formatted date/time
|
||||
// Loaded state — locale-formatted date/time
|
||||
it('formats date/time with Intl.DateTimeFormat and timezone', async () => {
|
||||
vi.mocked(api.GET).mockResolvedValue({
|
||||
data: fullEvent,
|
||||
error: undefined,
|
||||
response: new Response(null, { status: 200 }),
|
||||
} as never)
|
||||
mockLoadedEvent()
|
||||
|
||||
const wrapper = await mountWithToken()
|
||||
await flushPromises()
|
||||
|
||||
const dateField = wrapper.findAll('.detail__value')[0]!
|
||||
const dateField = wrapper.findAll('.detail__meta-text')[0]!
|
||||
expect(dateField.text()).toContain('(Europe/Berlin)')
|
||||
// The formatted date part is locale-dependent but should contain the year
|
||||
expect(dateField.text()).toContain('2026')
|
||||
wrapper.unmount()
|
||||
})
|
||||
|
||||
// T013: Loaded state — optional fields absent
|
||||
// Loaded state — optional fields absent
|
||||
it('does not render description and location when absent', async () => {
|
||||
vi.mocked(api.GET).mockResolvedValue({
|
||||
data: {
|
||||
...fullEvent,
|
||||
description: undefined,
|
||||
location: undefined,
|
||||
attendeeCount: 0,
|
||||
},
|
||||
error: undefined,
|
||||
response: new Response(null, { status: 200 }),
|
||||
} as never)
|
||||
mockLoadedEvent({ description: undefined, location: undefined, attendeeCount: 0 })
|
||||
|
||||
const wrapper = await mountWithToken()
|
||||
await flushPromises()
|
||||
@@ -109,38 +121,33 @@ describe('EventDetailView', () => {
|
||||
expect(wrapper.text()).not.toContain('Description')
|
||||
expect(wrapper.text()).not.toContain('Location')
|
||||
expect(wrapper.text()).toContain('0')
|
||||
wrapper.unmount()
|
||||
})
|
||||
|
||||
// T020 (US2): Expired state
|
||||
// Expired state
|
||||
it('renders "event has ended" banner when expired', async () => {
|
||||
vi.mocked(api.GET).mockResolvedValue({
|
||||
data: { ...fullEvent, expired: true },
|
||||
error: undefined,
|
||||
response: new Response(null, { status: 200 }),
|
||||
} as never)
|
||||
mockLoadedEvent({ expired: true })
|
||||
|
||||
const wrapper = await mountWithToken()
|
||||
await flushPromises()
|
||||
|
||||
expect(wrapper.text()).toContain('This event has ended.')
|
||||
expect(wrapper.find('.detail__banner--expired').exists()).toBe(true)
|
||||
wrapper.unmount()
|
||||
})
|
||||
|
||||
// T020 (US2): No expired banner when not expired
|
||||
// No expired banner when not expired
|
||||
it('does not render expired banner when event is active', async () => {
|
||||
vi.mocked(api.GET).mockResolvedValue({
|
||||
data: fullEvent,
|
||||
error: undefined,
|
||||
response: new Response(null, { status: 200 }),
|
||||
} as never)
|
||||
mockLoadedEvent()
|
||||
|
||||
const wrapper = await mountWithToken()
|
||||
await flushPromises()
|
||||
|
||||
expect(wrapper.find('.detail__banner--expired').exists()).toBe(false)
|
||||
wrapper.unmount()
|
||||
})
|
||||
|
||||
// T023 (US4): Not found state
|
||||
// Not found state
|
||||
it('renders "event not found" when API returns 404', async () => {
|
||||
vi.mocked(api.GET).mockResolvedValue({
|
||||
data: undefined,
|
||||
@@ -152,11 +159,11 @@ describe('EventDetailView', () => {
|
||||
await flushPromises()
|
||||
|
||||
expect(wrapper.text()).toContain('Event not found.')
|
||||
// No event data in DOM
|
||||
expect(wrapper.find('.detail__title').exists()).toBe(false)
|
||||
wrapper.unmount()
|
||||
})
|
||||
|
||||
// T027: Server error + retry
|
||||
// Server error + retry
|
||||
it('renders error state with retry button on server error', async () => {
|
||||
vi.mocked(api.GET).mockResolvedValue({
|
||||
data: undefined,
|
||||
@@ -169,9 +176,10 @@ describe('EventDetailView', () => {
|
||||
|
||||
expect(wrapper.text()).toContain('Something went wrong.')
|
||||
expect(wrapper.find('button').text()).toBe('Retry')
|
||||
wrapper.unmount()
|
||||
})
|
||||
|
||||
// T027: Retry button re-fetches
|
||||
// Retry button re-fetches
|
||||
it('retry button triggers a new fetch', async () => {
|
||||
vi.mocked(api.GET)
|
||||
.mockResolvedValueOnce({
|
||||
@@ -194,5 +202,167 @@ describe('EventDetailView', () => {
|
||||
await flushPromises()
|
||||
|
||||
expect(wrapper.find('.detail__title').text()).toBe('Summer BBQ')
|
||||
wrapper.unmount()
|
||||
})
|
||||
|
||||
// RSVP bar
|
||||
it('shows RSVP CTA bar on active event', async () => {
|
||||
mockLoadedEvent()
|
||||
|
||||
const wrapper = await mountWithToken()
|
||||
await flushPromises()
|
||||
|
||||
expect(wrapper.find('.rsvp-bar__cta').exists()).toBe(true)
|
||||
expect(wrapper.find('.rsvp-bar__cta').text()).toBe("I'm attending")
|
||||
wrapper.unmount()
|
||||
})
|
||||
|
||||
it('does not show RSVP bar for organizer', async () => {
|
||||
mockGetOrganizerToken.mockReturnValue('org-token-123')
|
||||
mockLoadedEvent()
|
||||
|
||||
const wrapper = await mountWithToken()
|
||||
await flushPromises()
|
||||
|
||||
expect(wrapper.find('.rsvp-bar').exists()).toBe(false)
|
||||
expect(wrapper.find('.rsvp-bar__cta').exists()).toBe(false)
|
||||
wrapper.unmount()
|
||||
})
|
||||
|
||||
it('does not show RSVP bar on expired event', async () => {
|
||||
mockLoadedEvent({ expired: true })
|
||||
|
||||
const wrapper = await mountWithToken()
|
||||
await flushPromises()
|
||||
|
||||
expect(wrapper.find('.rsvp-bar__cta').exists()).toBe(false)
|
||||
expect(wrapper.find('.rsvp-bar').exists()).toBe(false)
|
||||
wrapper.unmount()
|
||||
})
|
||||
|
||||
it('shows RSVP status bar when localStorage has RSVP', async () => {
|
||||
mockGetRsvp.mockReturnValue({ rsvpToken: 'rsvp-1', rsvpName: 'Max' })
|
||||
mockLoadedEvent()
|
||||
|
||||
const wrapper = await mountWithToken()
|
||||
await flushPromises()
|
||||
|
||||
expect(wrapper.find('.rsvp-bar__status').exists()).toBe(true)
|
||||
expect(wrapper.find('.rsvp-bar__text').text()).toBe("You're attending!")
|
||||
expect(wrapper.find('.rsvp-bar__cta').exists()).toBe(false)
|
||||
wrapper.unmount()
|
||||
})
|
||||
|
||||
// RSVP form submission
|
||||
it('opens bottom sheet when CTA is clicked', async () => {
|
||||
mockLoadedEvent()
|
||||
|
||||
const wrapper = await mountWithToken()
|
||||
await flushPromises()
|
||||
|
||||
expect(document.body.querySelector('[role="dialog"]')).toBeNull()
|
||||
|
||||
await wrapper.find('.rsvp-bar__cta').trigger('click')
|
||||
await flushPromises()
|
||||
|
||||
expect(document.body.querySelector('[role="dialog"]')).not.toBeNull()
|
||||
wrapper.unmount()
|
||||
})
|
||||
|
||||
it('shows validation error when submitting empty name', async () => {
|
||||
mockLoadedEvent()
|
||||
|
||||
const wrapper = await mountWithToken()
|
||||
await flushPromises()
|
||||
|
||||
await wrapper.find('.rsvp-bar__cta').trigger('click')
|
||||
await flushPromises()
|
||||
|
||||
// Form is inside Teleport — find via document.body
|
||||
const form = document.body.querySelector('.rsvp-form')! as HTMLFormElement
|
||||
form.dispatchEvent(new Event('submit', { bubbles: true }))
|
||||
await flushPromises()
|
||||
|
||||
expect(document.body.querySelector('.rsvp-form__field-error')?.textContent).toBe('Please enter your name.')
|
||||
expect(vi.mocked(api.POST)).not.toHaveBeenCalled()
|
||||
wrapper.unmount()
|
||||
})
|
||||
|
||||
it('submits RSVP, saves to storage, and shows status', async () => {
|
||||
mockLoadedEvent()
|
||||
vi.mocked(api.POST).mockResolvedValue({
|
||||
data: { rsvpToken: 'rsvp-token-1', name: 'Max' },
|
||||
error: undefined,
|
||||
response: new Response(null, { status: 201 }),
|
||||
} as never)
|
||||
|
||||
const wrapper = await mountWithToken()
|
||||
await flushPromises()
|
||||
|
||||
// Open sheet
|
||||
await wrapper.find('.rsvp-bar__cta').trigger('click')
|
||||
await flushPromises()
|
||||
|
||||
// Fill name via Teleported input
|
||||
const input = document.body.querySelector('#rsvp-name')! as HTMLInputElement
|
||||
input.value = 'Max'
|
||||
input.dispatchEvent(new Event('input', { bubbles: true }))
|
||||
await flushPromises()
|
||||
|
||||
// Submit form
|
||||
const form = document.body.querySelector('.rsvp-form')! as HTMLFormElement
|
||||
form.dispatchEvent(new Event('submit', { bubbles: true }))
|
||||
await flushPromises()
|
||||
|
||||
// Verify API call
|
||||
expect(vi.mocked(api.POST)).toHaveBeenCalledWith('/events/{token}/rsvps', {
|
||||
params: { path: { token: 'test-token' } },
|
||||
body: { name: 'Max' },
|
||||
})
|
||||
|
||||
// Verify storage
|
||||
expect(mockSaveRsvp).toHaveBeenCalledWith(
|
||||
'abc-123',
|
||||
'rsvp-token-1',
|
||||
'Max',
|
||||
'Summer BBQ',
|
||||
'2026-03-15T20:00:00+01:00',
|
||||
)
|
||||
|
||||
// Verify UI switched to status
|
||||
expect(wrapper.find('.rsvp-bar__text').text()).toBe("You're attending!")
|
||||
expect(wrapper.find('.rsvp-bar__cta').exists()).toBe(false)
|
||||
|
||||
// Verify attendee count incremented
|
||||
expect(wrapper.text()).toContain('13')
|
||||
|
||||
wrapper.unmount()
|
||||
})
|
||||
|
||||
it('shows error when RSVP submission fails', async () => {
|
||||
mockLoadedEvent()
|
||||
vi.mocked(api.POST).mockResolvedValue({
|
||||
data: undefined,
|
||||
error: { type: 'about:blank', title: 'Bad Request', status: 400 },
|
||||
response: new Response(null, { status: 400 }),
|
||||
} as never)
|
||||
|
||||
const wrapper = await mountWithToken()
|
||||
await flushPromises()
|
||||
|
||||
await wrapper.find('.rsvp-bar__cta').trigger('click')
|
||||
await flushPromises()
|
||||
|
||||
const input = document.body.querySelector('#rsvp-name')! as HTMLInputElement
|
||||
input.value = 'Max'
|
||||
input.dispatchEvent(new Event('input', { bubbles: true }))
|
||||
await flushPromises()
|
||||
|
||||
const form = document.body.querySelector('.rsvp-form')! as HTMLFormElement
|
||||
form.dispatchEvent(new Event('submit', { bubbles: true }))
|
||||
await flushPromises()
|
||||
|
||||
expect(document.body.textContent).toContain('Could not submit RSVP. Please try again.')
|
||||
wrapper.unmount()
|
||||
})
|
||||
})
|
||||
|
||||
@@ -8,7 +8,7 @@ function createTestRouter() {
|
||||
history: createMemoryHistory(),
|
||||
routes: [
|
||||
{ path: '/', name: 'home', component: { template: '<div />' } },
|
||||
{ path: '/events/:token', name: 'event', component: EventStubView },
|
||||
{ path: '/events/:eventToken', name: 'event', component: EventStubView },
|
||||
],
|
||||
})
|
||||
}
|
||||
|
||||
79
specs/008-rsvp/contracts/create-rsvp.yaml
Normal file
79
specs/008-rsvp/contracts/create-rsvp.yaml
Normal file
@@ -0,0 +1,79 @@
|
||||
# OpenAPI contract addition for POST /events/{eventToken}/rsvps
|
||||
# To be merged into backend/src/main/resources/openapi/api.yaml
|
||||
|
||||
paths:
|
||||
/events/{eventToken}/rsvps:
|
||||
post:
|
||||
operationId: createRsvp
|
||||
summary: Submit an RSVP for an event
|
||||
tags:
|
||||
- events
|
||||
parameters:
|
||||
- name: eventToken
|
||||
in: path
|
||||
required: true
|
||||
schema:
|
||||
type: string
|
||||
format: uuid
|
||||
description: Public event token
|
||||
requestBody:
|
||||
required: true
|
||||
content:
|
||||
application/json:
|
||||
schema:
|
||||
$ref: "#/components/schemas/CreateRsvpRequest"
|
||||
responses:
|
||||
"201":
|
||||
description: RSVP created successfully
|
||||
content:
|
||||
application/json:
|
||||
schema:
|
||||
$ref: "#/components/schemas/CreateRsvpResponse"
|
||||
"400":
|
||||
description: Validation failed (e.g. blank name)
|
||||
content:
|
||||
application/problem+json:
|
||||
schema:
|
||||
$ref: "#/components/schemas/ValidationProblemDetail"
|
||||
"404":
|
||||
description: Event not found
|
||||
content:
|
||||
application/problem+json:
|
||||
schema:
|
||||
$ref: "#/components/schemas/ProblemDetail"
|
||||
"409":
|
||||
description: Event has expired — RSVPs no longer accepted
|
||||
content:
|
||||
application/problem+json:
|
||||
schema:
|
||||
$ref: "#/components/schemas/ProblemDetail"
|
||||
|
||||
components:
|
||||
schemas:
|
||||
CreateRsvpRequest:
|
||||
type: object
|
||||
required:
|
||||
- name
|
||||
properties:
|
||||
name:
|
||||
type: string
|
||||
minLength: 1
|
||||
maxLength: 100
|
||||
description: Guest's display name
|
||||
example: "Max Mustermann"
|
||||
|
||||
CreateRsvpResponse:
|
||||
type: object
|
||||
required:
|
||||
- rsvpToken
|
||||
- name
|
||||
properties:
|
||||
rsvpToken:
|
||||
type: string
|
||||
format: uuid
|
||||
description: Token identifying this RSVP (store client-side for future updates)
|
||||
example: "d4e5f6a7-b8c9-0123-4567-890abcdef012"
|
||||
name:
|
||||
type: string
|
||||
description: Guest's display name as stored
|
||||
example: "Max Mustermann"
|
||||
93
specs/008-rsvp/data-model.md
Normal file
93
specs/008-rsvp/data-model.md
Normal file
@@ -0,0 +1,93 @@
|
||||
# Data Model: RSVP to an Event (008)
|
||||
|
||||
**Date**: 2026-03-06
|
||||
|
||||
## Entities
|
||||
|
||||
### Rsvp (NEW)
|
||||
|
||||
| Field | Type | Required | Constraints | Notes |
|
||||
|------------|----------------|----------|--------------------------------|------------------------------------|
|
||||
| id | Long | yes | BIGSERIAL, PK | Internal only, never exposed |
|
||||
| rsvpToken | RsvpToken | yes | UNIQUE, NOT NULL | Server-generated UUID, returned to client |
|
||||
| eventId | Long | yes | FK -> events.id, NOT NULL | Which event this RSVP belongs to |
|
||||
| name | String | yes | 1-100 chars, NOT NULL | Guest's display name |
|
||||
|
||||
**Notes**:
|
||||
- No `attending` boolean — existence of an entry implies attendance (per spec).
|
||||
- No `createdAt` — not required by the spec. Can be added later if needed (e.g. for guest list sorting in 009).
|
||||
- Duplicates from different devices or cleared localStorage are accepted (privacy trade-off).
|
||||
|
||||
### Token Value Objects (NEW)
|
||||
|
||||
| Record | Field | Type | Notes |
|
||||
|------------------|-------|------|-----------------------------------------------|
|
||||
| `EventToken` | value | UUID | Immutable, non-null. Java record wrapping UUID |
|
||||
| `OrganizerToken` | value | UUID | Immutable, non-null. Java record wrapping UUID |
|
||||
| `RsvpToken` | value | UUID | Immutable, non-null. Java record wrapping UUID |
|
||||
|
||||
**Purpose**: Type-safe wrappers preventing mix-ups between the three token types at compile time. All generated server-side via `UUID.randomUUID()`. JPA entities continue to use raw `UUID` columns — mapping happens in the persistence adapters.
|
||||
|
||||
### Event (MODIFIED — token fields change type)
|
||||
|
||||
The Event domain model's `eventToken` and `organizerToken` fields change from raw `UUID` to their typed record wrappers. No database schema change — the JPA entity keeps raw `UUID` columns.
|
||||
|
||||
| Field | Old Type | New Type |
|
||||
|-----------------|----------|------------------|
|
||||
| eventToken | UUID | EventToken |
|
||||
| organizerToken | UUID | OrganizerToken |
|
||||
|
||||
The `attendeeCount` was already added to the API response in 007-view-event — it now gets populated from a count query instead of returning 0.
|
||||
|
||||
### StoredEvent (frontend localStorage — modified)
|
||||
|
||||
| Field | Type | Required | Notes |
|
||||
|----------------|--------|----------|------------------------------------|
|
||||
| eventToken | string | yes | Existing |
|
||||
| organizerToken | string | no | Existing (organizer flow) |
|
||||
| title | string | yes | Existing |
|
||||
| dateTime | string | yes | Existing |
|
||||
| expiryDate | string | yes | Existing |
|
||||
| rsvpToken | string | no | **NEW** — set after RSVP submission |
|
||||
| rsvpName | string | no | **NEW** — guest's submitted name |
|
||||
|
||||
## Validation Rules
|
||||
|
||||
- `name`: required, 1-100 characters, trimmed. Blank or whitespace-only is rejected.
|
||||
- `rsvpToken`: server-generated, never from client input on create.
|
||||
- `eventId`: must reference an existing, non-expired event.
|
||||
|
||||
## Relationships
|
||||
|
||||
```
|
||||
Event 1 <---- * Rsvp
|
||||
| |
|
||||
eventToken rsvpToken (unique)
|
||||
(public) (returned to client)
|
||||
```
|
||||
|
||||
## Type Mapping (full stack)
|
||||
|
||||
| Concept | Java | PostgreSQL | OpenAPI | TypeScript |
|
||||
|--------------|-------------------|---------------|---------------------|------------|
|
||||
| RSVP ID | `Long` | `bigserial` | N/A (not exposed) | N/A |
|
||||
| RSVP Token | `RsvpToken` | `uuid` | `string` `uuid` | `string` |
|
||||
| Event FK | `Long` | `bigint` | N/A (path param) | N/A |
|
||||
| Guest name | `String` | `varchar(100)`| `string` | `string` |
|
||||
| Attendee cnt | `long` | `count(*)` | `integer` | `number` |
|
||||
|
||||
## Database Migration
|
||||
|
||||
New Liquibase changeset `003-create-rsvps-table.xml`:
|
||||
|
||||
```sql
|
||||
CREATE TABLE rsvps (
|
||||
id BIGSERIAL PRIMARY KEY,
|
||||
rsvp_token UUID NOT NULL UNIQUE,
|
||||
event_id BIGINT NOT NULL REFERENCES events(id),
|
||||
name VARCHAR(100) NOT NULL
|
||||
);
|
||||
|
||||
CREATE INDEX idx_rsvps_event_id ON rsvps(event_id);
|
||||
CREATE INDEX idx_rsvps_rsvp_token ON rsvps(rsvp_token);
|
||||
```
|
||||
114
specs/008-rsvp/plan.md
Normal file
114
specs/008-rsvp/plan.md
Normal file
@@ -0,0 +1,114 @@
|
||||
# Implementation Plan: RSVP to an Event
|
||||
|
||||
**Branch**: `008-rsvp` | **Date**: 2026-03-06 | **Spec**: [spec.md](spec.md)
|
||||
**Input**: Feature specification from `/specs/008-rsvp/spec.md`
|
||||
|
||||
## Summary
|
||||
|
||||
Add RSVP functionality to the event detail page. Backend: new `POST /api/events/{eventToken}/rsvps` endpoint that persists an RSVP (guest name) and returns an `rsvpToken`. Populates the existing `attendeeCount` field with real data from a count query. Rejects RSVPs on expired events (409). Frontend: fullscreen event presentation with sticky bottom bar (RSVP CTA or status), bottom sheet with RSVP form (name + submit). localStorage stores rsvpToken and name per event. No account required.
|
||||
|
||||
## Technical Context
|
||||
|
||||
**Language/Version**: Java 25 (backend), TypeScript 5.9 (frontend)
|
||||
**Primary Dependencies**: Spring Boot 3.5.x, Vue 3, Vue Router 5, openapi-fetch, openapi-typescript
|
||||
**Storage**: PostgreSQL (JPA via Spring Data, Liquibase migrations)
|
||||
**Testing**: JUnit (backend), Vitest (frontend unit), Playwright + MSW (frontend E2E)
|
||||
**Target Platform**: Self-hosted web application (Docker)
|
||||
**Project Type**: Web service + SPA
|
||||
**Performance Goals**: N/A (single-user scale, self-hosted)
|
||||
**Constraints**: No external resources (CDNs, fonts, tracking), WCAG AA, privacy-first, no PII logging
|
||||
**Scale/Scope**: New RSVP domain (model + service + controller + persistence), new frontend components (bottom sheet, sticky bar), modified event detail view
|
||||
|
||||
## Constitution Check
|
||||
|
||||
*GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.*
|
||||
|
||||
| Principle | Status | Notes |
|
||||
|-----------|--------|-------|
|
||||
| I. Privacy by Design | PASS | No PII logged. Only guest-entered name stored. No IP logging. No tracking. Attendee names not exposed publicly (count only). Unprotected endpoint is a conscious privacy trade-off per spec. |
|
||||
| II. Test-Driven Methodology | PASS | TDD enforced: backend unit + integration tests, frontend unit tests, E2E tests. Tests written before implementation. |
|
||||
| III. API-First Development | PASS | OpenAPI spec updated first. New endpoint + schemas with `example:` fields. Types generated before implementation. |
|
||||
| IV. Simplicity & Quality | PASS | Minimal scope: one POST endpoint, one domain entity, one bottom sheet component. No CAPTCHA, no rate limiting, no edit/withdraw (deferred). Cancelled event guard deferred to US-18. |
|
||||
| V. Dependency Discipline | PASS | No new dependencies. Bottom sheet is CSS + Vue (~50 lines). No UI library. |
|
||||
| VI. Accessibility | PASS | Bottom sheet uses dialog role + aria-modal. Focus trap. ESC to close. Keyboard navigable. WCAG AA contrast via design system. |
|
||||
|
||||
**Post-Phase-1 re-check**: All gates still pass. Three token value objects (`EventToken`, `OrganizerToken`, `RsvpToken`) introduced uniformly — justified by spec requirement for type-safe tokens. Refactoring existing Event model to use typed tokens is a mechanical change well-covered by existing tests.
|
||||
|
||||
## Project Structure
|
||||
|
||||
### Documentation (this feature)
|
||||
|
||||
```text
|
||||
specs/008-rsvp/
|
||||
├── plan.md # This file
|
||||
├── spec.md # Feature specification
|
||||
├── research.md # Phase 0: research decisions (R-1 through R-8)
|
||||
├── data-model.md # Phase 1: Rsvp entity, RsvpToken value object
|
||||
├── quickstart.md # Phase 1: implementation overview
|
||||
├── contracts/
|
||||
│ └── create-rsvp.yaml # Phase 1: POST endpoint contract
|
||||
└── tasks.md # Phase 2: implementation tasks (via /speckit.tasks)
|
||||
```
|
||||
|
||||
### Source Code (repository root)
|
||||
|
||||
```text
|
||||
backend/
|
||||
├── src/main/java/de/fete/
|
||||
│ ├── domain/
|
||||
│ │ ├── model/
|
||||
│ │ │ ├── Event.java # MODIFIED: UUID → EventToken/OrganizerToken
|
||||
│ │ │ ├── EventToken.java # NEW: typed token record
|
||||
│ │ │ ├── OrganizerToken.java # NEW: typed token record
|
||||
│ │ │ ├── Rsvp.java # NEW: RSVP domain entity
|
||||
│ │ │ └── RsvpToken.java # NEW: typed token record
|
||||
│ │ └── port/
|
||||
│ │ ├── in/CreateRsvpUseCase.java # NEW: inbound port
|
||||
│ │ └── out/RsvpRepository.java # NEW: outbound port
|
||||
│ ├── application/service/
|
||||
│ │ ├── EventService.java # MODIFIED: use typed tokens
|
||||
│ │ └── RsvpService.java # NEW: RSVP business logic
|
||||
│ ├── adapter/
|
||||
│ │ ├── in/web/
|
||||
│ │ │ ├── EventController.java # MODIFIED: typed tokens + attendee count + createRsvp()
|
||||
│ │ │ └── GlobalExceptionHandler.java # MODIFIED: handle EventExpiredException
|
||||
│ │ └── out/persistence/
|
||||
│ │ ├── EventPersistenceAdapter.java # MODIFIED: map typed tokens
|
||||
│ │ ├── RsvpJpaEntity.java # NEW: JPA entity
|
||||
│ │ ├── RsvpJpaRepository.java # NEW: Spring Data interface
|
||||
│ │ └── RsvpPersistenceAdapter.java # NEW: port implementation
|
||||
├── src/main/resources/
|
||||
│ ├── openapi/api.yaml # MODIFIED: add RSVP endpoint + schemas
|
||||
│ └── db/changelog/
|
||||
│ ├── db.changelog-master.xml # MODIFIED: include 003
|
||||
│ └── 003-create-rsvps-table.xml # NEW: rsvps table
|
||||
└── src/test/java/de/fete/
|
||||
├── application/service/
|
||||
│ ├── EventServiceTest.java # MODIFIED: use typed tokens
|
||||
│ └── RsvpServiceTest.java # NEW: unit tests
|
||||
└── adapter/in/web/
|
||||
└── EventControllerIntegrationTest.java # MODIFIED: typed tokens + RSVP integration tests
|
||||
|
||||
frontend/
|
||||
├── src/
|
||||
│ ├── api/schema.d.ts # REGENERATED from OpenAPI
|
||||
│ ├── components/
|
||||
│ │ ├── BottomSheet.vue # NEW: reusable bottom sheet
|
||||
│ │ └── RsvpBar.vue # NEW: sticky bottom bar
|
||||
│ ├── views/EventDetailView.vue # MODIFIED: integrate RSVP bar + sheet
|
||||
│ ├── composables/useEventStorage.ts # MODIFIED: add rsvpToken/rsvpName
|
||||
│ └── assets/main.css # MODIFIED: bottom sheet + bar styles
|
||||
├── src/views/__tests__/EventDetailView.spec.ts # MODIFIED: RSVP integration tests
|
||||
├── src/components/__tests__/
|
||||
│ ├── BottomSheet.spec.ts # NEW: unit tests
|
||||
│ └── RsvpBar.spec.ts # NEW: unit tests
|
||||
├── src/composables/__tests__/useEventStorage.spec.ts # MODIFIED: test new fields
|
||||
└── e2e/
|
||||
└── event-rsvp.spec.ts # NEW: E2E tests
|
||||
```
|
||||
|
||||
**Structure Decision**: Extends the existing web application structure (backend + frontend). Adds a new RSVP domain following the same hexagonal architecture pattern established in 006-create-event and 007-view-event. Cross-cutting refactoring introduces typed token value objects (`EventToken`, `OrganizerToken`, `RsvpToken`) across all layers. Two new frontend components (`BottomSheet`, `RsvpBar`) are the first entries in `src/components/` — justified because they're reusable UI primitives, not view-specific markup.
|
||||
|
||||
## Complexity Tracking
|
||||
|
||||
No constitution violations. No entries needed.
|
||||
58
specs/008-rsvp/quickstart.md
Normal file
58
specs/008-rsvp/quickstart.md
Normal file
@@ -0,0 +1,58 @@
|
||||
# Quickstart: RSVP to an Event (008)
|
||||
|
||||
## What this feature adds
|
||||
|
||||
1. **Backend**: New `POST /api/events/{eventToken}/rsvps` endpoint that accepts an RSVP (guest name) and returns an `rsvpToken`. Populates the existing `attendeeCount` field in `GET /events/{token}` with real data.
|
||||
|
||||
2. **Frontend**: Bottom sheet RSVP form on the event detail page. Sticky bottom bar with CTA (or status after RSVP). localStorage persistence of RSVP data.
|
||||
|
||||
## Implementation order
|
||||
|
||||
1. **Token value objects** — Create `EventToken`, `OrganizerToken`, `RsvpToken` records. Refactor `Event` domain model and all layers (service, controller, repository, persistence adapter, tests) to use typed tokens instead of raw UUID.
|
||||
2. **OpenAPI spec** — Add `CreateRsvpRequest`, `CreateRsvpResponse`, and the `POST /events/{eventToken}/rsvps` endpoint.
|
||||
3. **Liquibase migration** — Create `rsvps` table (003-create-rsvps-table.xml).
|
||||
4. **Domain model** — `Rsvp` entity using `RsvpToken`.
|
||||
5. **Ports** — `CreateRsvpUseCase` (in), `RsvpRepository` (out).
|
||||
6. **Persistence adapter** — `RsvpJpaEntity`, `RsvpJpaRepository`, `RsvpPersistenceAdapter`.
|
||||
7. **Service** — `RsvpService` implementing `CreateRsvpUseCase`.
|
||||
8. **Controller** — Add `createRsvp()` to `EventController`.
|
||||
9. **Attendee count** — Wire `RsvpRepository.countByEventId()` into the GET event flow.
|
||||
10. **Frontend composable** — Extend `useEventStorage` with `rsvpToken`/`rsvpName`.
|
||||
11. **Frontend UI** — Bottom sheet component, sticky bar, RSVP form.
|
||||
12. **E2E tests** — RSVP submission, expired event guard, localStorage verification.
|
||||
|
||||
## Key files to touch
|
||||
|
||||
### Backend (new)
|
||||
- `domain/model/EventToken.java`
|
||||
- `domain/model/OrganizerToken.java`
|
||||
- `domain/model/Rsvp.java`
|
||||
- `domain/model/RsvpToken.java`
|
||||
- `domain/port/in/CreateRsvpUseCase.java`
|
||||
- `domain/port/out/RsvpRepository.java`
|
||||
- `application/service/RsvpService.java`
|
||||
- `adapter/out/persistence/RsvpJpaEntity.java`
|
||||
- `adapter/out/persistence/RsvpJpaRepository.java`
|
||||
- `adapter/out/persistence/RsvpPersistenceAdapter.java`
|
||||
- `db/changelog/003-create-rsvps-table.xml`
|
||||
|
||||
### Backend (modified)
|
||||
- `domain/model/Event.java` — UUID → EventToken/OrganizerToken
|
||||
- `application/service/EventService.java` — use typed tokens
|
||||
- `adapter/in/web/EventController.java` — typed tokens + wire attendee count + createRsvp()
|
||||
- `adapter/in/web/GlobalExceptionHandler.java` — handle `EventExpiredException` (409)
|
||||
- `adapter/out/persistence/EventPersistenceAdapter.java` — map typed tokens
|
||||
- `domain/port/out/EventRepository.java` — typed token in signature
|
||||
- `openapi/api.yaml` — new endpoint + schemas
|
||||
- `db/changelog/db.changelog-master.xml` — include new migration
|
||||
- All existing tests — update to use typed tokens
|
||||
|
||||
### Frontend (new)
|
||||
- `src/components/BottomSheet.vue` — reusable bottom sheet
|
||||
- `src/components/RsvpBar.vue` — sticky bottom bar (CTA or status)
|
||||
- `e2e/event-rsvp.spec.ts` — E2E tests
|
||||
|
||||
### Frontend (modified)
|
||||
- `src/views/EventDetailView.vue` — integrate RSVP bar + bottom sheet
|
||||
- `src/composables/useEventStorage.ts` — add rsvpToken/rsvpName fields
|
||||
- `src/api/schema.d.ts` — regenerated from OpenAPI
|
||||
157
specs/008-rsvp/research.md
Normal file
157
specs/008-rsvp/research.md
Normal file
@@ -0,0 +1,157 @@
|
||||
# Research: RSVP to an Event (008)
|
||||
|
||||
**Date**: 2026-03-06 | **Status**: Complete
|
||||
|
||||
## R-1: RSVP Endpoint Design
|
||||
|
||||
**Decision**: `POST /api/events/{eventToken}/rsvps` creates an RSVP. Returns `201` with `rsvpToken` on success. Rejects with `409 Conflict` if event expired.
|
||||
|
||||
**Rationale**: RSVPs are a sub-resource of events — nesting under the event token is RESTful and groups operations logically. The event token in the path identifies the event; no separate event ID in the request body needed.
|
||||
|
||||
**Flow**:
|
||||
1. `EventController` implements generated `EventsApi.createRsvp()` — same controller, same tag, sub-resource of events.
|
||||
2. Controller resolves the event via `eventToken`, checks expiry.
|
||||
3. New inbound port: `CreateRsvpUseCase` with `createRsvp(CreateRsvpCommand): Rsvp`.
|
||||
4. `RsvpService` validates event exists + not expired, persists RSVP, returns domain model.
|
||||
5. Controller maps to `CreateRsvpResponse` DTO (contains `rsvpToken`).
|
||||
6. 404 if event not found, 409 if event expired, 400 for validation errors.
|
||||
|
||||
**Alternatives considered**:
|
||||
- `POST /api/rsvps` with eventToken in body — rejected because RSVPs are always scoped to an event. Nested resource is cleaner.
|
||||
- Separate `RsvpController` — rejected because the URL is under `/events/`, so it belongs in `EventController`. One controller per resource root (KISS).
|
||||
- `PUT` instead of `POST` — rejected because the client doesn't know the rsvpToken before creation.
|
||||
|
||||
## R-2: Token Value Objects
|
||||
|
||||
**Decision**: Introduce all three token types as Java records wrapping `UUID`: `EventToken`, `OrganizerToken`, and `RsvpToken`. Refactor the existing `Event` domain model and all layers (service, controller, repository, persistence adapter) to use the typed tokens instead of raw `UUID`.
|
||||
|
||||
**Rationale**: The spec mandates typed token records. Introducing `RsvpToken` alone while leaving the other two as raw UUIDs would create an inconsistency in the domain model. All three tokens serve the same purpose (type-safe identification) and should be modeled uniformly. The cross-cutting refactoring touches existing code but is mechanical and well-covered by existing tests.
|
||||
|
||||
**Implementation pattern** (same for all three):
|
||||
```java
|
||||
package de.fete.domain.model;
|
||||
|
||||
public record EventToken(UUID value) {
|
||||
public EventToken {
|
||||
Objects.requireNonNull(value, "eventToken must not be null");
|
||||
}
|
||||
|
||||
public static EventToken generate() {
|
||||
return new EventToken(UUID.randomUUID());
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
```java
|
||||
public record OrganizerToken(UUID value) { /* same pattern */ }
|
||||
public record RsvpToken(UUID value) { /* same pattern */ }
|
||||
```
|
||||
|
||||
**Impact on existing code**:
|
||||
- `Event.java`: `UUID eventToken` → `EventToken eventToken`, `UUID organizerToken` → `OrganizerToken organizerToken`
|
||||
- `EventService.java`: `UUID.randomUUID()` → `EventToken.generate()` / `OrganizerToken.generate()`
|
||||
- `EventController.java`: unwrap tokens at API boundary (`token.value()`)
|
||||
- `EventRepository.java` / `EventPersistenceAdapter.java`: map between domain tokens and raw UUIDs for JPA
|
||||
- `EventJpaEntity.java`: stays with raw `UUID` columns (JPA mapping layer)
|
||||
- All existing tests: update to use typed tokens
|
||||
|
||||
**Alternatives considered**:
|
||||
- Use raw UUID everywhere — rejected because the spec explicitly requires typed records and they prevent mixing up token types at compile time.
|
||||
- Introduce only `RsvpToken` now — rejected because it creates an inconsistency. All three should be uniform.
|
||||
|
||||
## R-3: Attendee Count Population
|
||||
|
||||
**Decision**: Populate `attendeeCount` in `GetEventResponse` by counting RSVP rows for the event. The count query lives in the `RsvpRepository` port and is called by `EventService` (or a query in `RsvpService` delegated to by `EventController`).
|
||||
|
||||
**Rationale**: The `attendeeCount` field already exists in the API contract (returns 0 today per R-3 in 007). Now it gets real data. Since an RSVP entry's existence implies attendance (no `attending` boolean), the count is simply `COUNT(*) WHERE event_id = ?`.
|
||||
|
||||
**Implementation approach**: Add `countByEventId(Long eventId)` to `RsvpRepository`. `EventService.getByEventToken()` returns the Event domain object; the controller queries the RSVP count separately and sets it on the response. This keeps Event and RSVP domains loosely coupled.
|
||||
|
||||
**Alternatives considered**:
|
||||
- Store count on the Event entity (denormalized) — rejected because it introduces update anomalies and requires synchronization logic.
|
||||
- Join query in EventRepository — rejected because it couples Event persistence to RSVP schema.
|
||||
|
||||
## R-4: Expired Event Guard
|
||||
|
||||
**Decision**: Both client and server enforce the expiry guard. Client hides the RSVP form when `expired === true` (from GetEventResponse). Server rejects `POST /rsvps` with `409 Conflict` when `event.expiryDate < today`.
|
||||
|
||||
**Rationale**: Defense in depth. The client check is UX (don't show a form that can't succeed). The server check is the authoritative guard (clients can be bypassed). Using `409 Conflict` rather than `400 Bad Request` because the request format is valid — it's the event state that prevents the operation.
|
||||
|
||||
**Alternatives considered**:
|
||||
- Client-only guard — rejected because clients can be bypassed.
|
||||
- `400 Bad Request` — rejected because the request body is valid; the conflict is with the event's state.
|
||||
- `422 Unprocessable Entity` — acceptable but `409` better communicates "the resource state conflicts with this operation."
|
||||
|
||||
## R-5: localStorage Schema for RSVP
|
||||
|
||||
**Decision**: Extend the existing `fete:events` localStorage structure. Each `StoredEvent` entry gains optional `rsvpToken` and `rsvpName` fields.
|
||||
|
||||
**Rationale**: The existing `useEventStorage` composable already stores events by token. Adding RSVP data to the same entry avoids a second localStorage key and keeps event data co-located. The spec requires storing: rsvpToken, name, event token, event title, event date — the last three are already in `StoredEvent`.
|
||||
|
||||
**Schema change**:
|
||||
```typescript
|
||||
interface StoredEvent {
|
||||
eventToken: string
|
||||
organizerToken?: string // existing (for organizers)
|
||||
title: string // existing
|
||||
dateTime: string // existing
|
||||
expiryDate: string // existing
|
||||
rsvpToken?: string // NEW — present after RSVP
|
||||
rsvpName?: string // NEW — guest's submitted name
|
||||
}
|
||||
```
|
||||
|
||||
**Alternatives considered**:
|
||||
- Separate `fete:rsvps` localStorage key — rejected because it duplicates event metadata (title, date) and complicates lookups.
|
||||
- IndexedDB — rejected (over-engineering for a few KBs of data).
|
||||
|
||||
## R-6: Bottom Sheet UI Pattern
|
||||
|
||||
**Decision**: Implement the bottom sheet as a Vue component using CSS transforms and transitions. No UI library dependency.
|
||||
|
||||
**Rationale**: The spec requires a bottom sheet for the RSVP form. A custom implementation using `transform: translateY()` with CSS transitions is lightweight, accessible, and avoids new dependencies (Principle V). The sheet slides up from the bottom on open and back down on close.
|
||||
|
||||
**Key implementation details**:
|
||||
- Overlay backdrop (semi-transparent) with click-to-dismiss
|
||||
- `<dialog>` element or ARIA `role="dialog"` with `aria-modal="true"`
|
||||
- Focus trap inside the sheet (keyboard accessibility)
|
||||
- ESC key to close
|
||||
- Transition: `transform 0.3s ease-out`
|
||||
- Mobile: full-width, max-height ~50vh. Desktop: full-width within the 480px column.
|
||||
|
||||
**Alternatives considered**:
|
||||
- Modal/dialog instead of bottom sheet — rejected because bottom sheets are the mobile-native pattern for contextual actions.
|
||||
- Headless UI library (e.g., @headlessui/vue) — rejected because it adds a dependency for a single component. Custom implementation is ~50 lines.
|
||||
|
||||
## R-7: Sticky Bottom Bar
|
||||
|
||||
**Decision**: The sticky bar is a `position: fixed` element at the bottom of the viewport, within the content column (max 480px). It contains either the RSVP CTA button or the RSVP status text.
|
||||
|
||||
**Rationale**: The spec defines two states for the bar:
|
||||
1. **No RSVP**: Shows CTA button (accent color, "Ich bin dabei!" or similar)
|
||||
2. **Has RSVP**: Shows status text ("Du kommst!" + edit hint, though edit is out of scope)
|
||||
|
||||
The bar state is determined by checking localStorage for an rsvpToken for the current event.
|
||||
|
||||
**CSS pattern**:
|
||||
```css
|
||||
.sticky-bar {
|
||||
position: fixed;
|
||||
bottom: 0;
|
||||
left: 50%;
|
||||
transform: translateX(-50%);
|
||||
width: 100%;
|
||||
max-width: 480px; /* matches content column */
|
||||
padding: 1rem 1.2rem;
|
||||
/* glass-morphism or solid surface */
|
||||
}
|
||||
```
|
||||
|
||||
**Alternatives considered**:
|
||||
- `position: sticky` at bottom of content — rejected because it only sticks within the scroll container, not the viewport. Fixed is needed for always-visible CTA.
|
||||
|
||||
## R-8: Cancelled Event Guard (Deferred)
|
||||
|
||||
**Decision**: FR-010 (cancelled event guard) is deferred per spec. The code will NOT check for cancellation status. This will be added when US-18 (cancel event) is implemented.
|
||||
|
||||
**Rationale**: No cancellation field exists on the Event model yet. Adding a guard for a non-existent state violates KISS (Principle IV).
|
||||
@@ -5,11 +5,25 @@
|
||||
**Status**: Draft
|
||||
**Source**: Migrated from spec/userstories.md
|
||||
|
||||
## Clarifications
|
||||
|
||||
### Session 2026-03-06
|
||||
|
||||
- Q: How should the server deduplicate RSVPs from the same device without accounts? → A: Server generates an `rsvpToken` (UUID) on first RSVP, returns it to the client. Client stores it in localStorage per event. On re-RSVP, client sends the `rsvpToken` to update instead of create. No global device identifier — the token is event-scoped. If localStorage is lost (cleared or different device), a duplicate entry is accepted as a privacy trade-off.
|
||||
- Q: Should typed token value objects be used in the backend? → A: Yes. Backend: The three token types (EventToken, OrganizerToken, RsvpToken) MUST be modeled as distinct Java record types wrapping UUID, not passed as raw UUID values. Frontend: No branded types — plain string variables with clear naming (eventToken, rsvpToken) are sufficient given TypeScript's structural typing and OpenAPI codegen.
|
||||
- Q: How should the RSVP interaction be presented on the event page? → A: Fullscreen event presentation (gradient background, later Unsplash). Title prominent at top, key facts below (description, date, attendee count) — spacious layout. Sticky bottom bar with RSVP CTA. Tap opens a bottom sheet with the RSVP form. After RSVP, the bar shows status ("Du kommst!" + edit option) instead of the CTA.
|
||||
- Q: How does the RSVP form handle declining? → A: There is no explicit "not attending" button. The bottom sheet only offers the attending flow (name + submit). To not attend, the guest simply closes the sheet. Withdrawing an existing RSVP (DELETE with rsvpToken) is out of scope — deferred to a separate edit-RSVP spec.
|
||||
- Q: Should the attendee name list be publicly visible on the event page? → A: No. Only the attendee count is shown publicly. The full name list is visible only to the organizer (via organizer link). This maximizes guest privacy.
|
||||
- Q: Should the RSVP endpoint have spam/abuse protection? → A: No. The RSVP endpoint is intentionally unprotected — risk is consciously accepted as a privacy trade-off consistent with the no-account, no-tracking philosophy. Protection measures can be retrofitted in a separate spec if real-world abuse occurs. KISS.
|
||||
- Q: How is the attendee count delivered and updated? → A: As a new `attendeeCount` field in the existing Event response (no separate endpoint). Loaded once on page load, no polling or WebSocket. After the guest's own RSVP submission, the count is optimistically incremented (+1) client-side. KISS.
|
||||
- Q: What determines the RSVP cutoff? → A: The event date itself. No separate expiry field. After the event date has passed, RSVPs are blocked (form hidden, server rejects).
|
||||
- Q: Should the RSVP entity have an `attending` boolean field? → A: No. The server only stores attending RSVPs — existence of an entry implies attendance. No `attending` boolean needed. Deletion of entries (withdrawal) is deferred to the edit-RSVP spec.
|
||||
|
||||
## User Scenarios & Testing
|
||||
|
||||
### User Story 1 - Submit an RSVP (Priority: P1)
|
||||
|
||||
A guest opens an active event page and indicates whether they will attend. If attending, they must provide their name. If not attending, the name is optional. The RSVP is sent to the server and persisted. The guest's choice, name, event token, title, and date are saved in localStorage.
|
||||
A guest opens an active event page, which presents the event fullscreen (gradient background, title prominent at top, key facts below including attendee count). A sticky bottom bar shows an RSVP call-to-action. Tapping opens a bottom sheet with the RSVP form: name field + submit. The RSVP is sent to the server and persisted. The server returns an rsvpToken which, along with the name, event token, title, and date, is saved in localStorage. After submission, the bottom sheet closes and the sticky bar shows the guest's RSVP status. To not attend, the guest simply closes the sheet — no server request.
|
||||
|
||||
**Why this priority**: Core interactive feature of the app. Without it, guests cannot communicate attendance, and the attendee list (US-2) has no data.
|
||||
|
||||
@@ -17,30 +31,15 @@ A guest opens an active event page and indicates whether they will attend. If at
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a guest is on an active event page, **When** they select "I'm attending" and enter their name, **Then** the RSVP is submitted to the server, persisted, and the attendee list reflects the new entry.
|
||||
2. **Given** a guest is on an active event page, **When** they select "I'm attending" but leave the name blank, **Then** the form is not submitted and a validation message indicating the name is required is shown.
|
||||
3. **Given** a guest is on an active event page, **When** they select "I'm not attending" without entering a name, **Then** the RSVP is submitted successfully (name is optional for non-attendees).
|
||||
4. **Given** a guest submits an RSVP (attending or not), **When** the submission succeeds, **Then** the guest's RSVP choice, name, event token, event title, and event date are stored in localStorage on this device.
|
||||
5. **Given** a guest submits an RSVP, **When** the submission succeeds, **Then** no account, login, or personal data beyond the optionally entered name is required.
|
||||
1. **Given** a guest is on an active event page, **When** they tap the RSVP CTA, enter their name, and submit, **Then** the RSVP is submitted to the server, persisted, and the attendee count updates.
|
||||
2. **Given** a guest has opened the bottom sheet, **When** they leave the name blank and try to submit, **Then** the form is not submitted and a validation message is shown.
|
||||
3. **Given** a guest has opened the bottom sheet, **When** they close it without submitting, **Then** no server request is made and no state changes.
|
||||
4. **Given** a guest submits an RSVP, **When** the submission succeeds, **Then** the rsvpToken, name, event token, event title, and event date are stored in localStorage on this device.
|
||||
5. **Given** a guest submits an RSVP, **When** the submission succeeds, **Then** no account, login, or personal data beyond the entered name is required.
|
||||
|
||||
---
|
||||
|
||||
### User Story 2 - Re-RSVP from the Same Device (Priority: P2)
|
||||
|
||||
A returning guest on the same device opens an event page where they previously submitted an RSVP. The form pre-fills with their prior choice and name. Re-submitting updates the existing RSVP rather than creating a duplicate.
|
||||
|
||||
**Why this priority**: Prevents duplicate entries and provides a better UX for guests who want to change their mind. Depends on Story 1 populating localStorage.
|
||||
|
||||
**Independent Test**: Can be tested by RSVPing once, then reloading the event page and verifying the form is pre-filled and a second submission updates rather than duplicates the server-side record.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a guest has previously submitted an RSVP on this device, **When** they open the same event page again, **Then** the RSVP form is pre-filled with their previous choice and name.
|
||||
2. **Given** a guest has a prior RSVP pre-filled, **When** they change their selection and re-submit, **Then** the existing server-side RSVP entry is updated and no duplicate entry is created.
|
||||
|
||||
---
|
||||
|
||||
### User Story 3 - RSVP Blocked on Expired or Cancelled Events (Priority: P2)
|
||||
### User Story 2 - RSVP Blocked on Expired or Cancelled Events (Priority: P2)
|
||||
|
||||
A guest attempts to RSVP to an event that has already expired or has been cancelled. The RSVP form is not shown and the server rejects any submission attempts.
|
||||
|
||||
@@ -58,37 +57,40 @@ A guest attempts to RSVP to an event that has already expired or has been cancel
|
||||
|
||||
### Edge Cases
|
||||
|
||||
- What happens when a guest RSVPs on two different devices? Each device stores its own localStorage entry; the server holds both RSVPs as separate entries (no deduplication across devices — acceptable per design, consistent with the no-account model).
|
||||
- What happens when a guest RSVPs on two different devices? Each device stores its own localStorage entry; the server holds both RSVPs as separate entries (no deduplication across devices — accepted privacy trade-off).
|
||||
- What happens when the server is unreachable during RSVP submission? The submission fails; localStorage is not updated (no optimistic write). The guest sees an error and can retry.
|
||||
- What happens if localStorage is cleared after RSVPing? The form no longer pre-fills and the guest can re-submit; the server will create a new RSVP entry rather than update the old one.
|
||||
- What happens if localStorage is cleared after RSVPing? The sticky bar shows the CTA again (as if no prior RSVP). A new submission creates a duplicate server-side entry — accepted privacy trade-off.
|
||||
- What about spam/abuse on the unprotected RSVP endpoint? Risk is consciously accepted (KISS, privacy-first). No rate limiting, no honeypot, no CAPTCHA. Can be retrofitted in a future spec if real-world abuse occurs.
|
||||
|
||||
## Requirements
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-001**: The RSVP form MUST offer exactly two choices: "I'm attending" and "I'm not attending".
|
||||
- **FR-002**: When the guest selects "I'm attending", the name field MUST be required; submission MUST be blocked if the name is blank.
|
||||
- **FR-003**: When the guest selects "I'm not attending", the name field MUST be optional; submission MUST succeed without a name.
|
||||
- **FR-004**: On successful RSVP submission, the server MUST persist the RSVP associated with the event.
|
||||
- **FR-005**: On successful RSVP submission, the client MUST store the guest's RSVP choice and name in localStorage, keyed by event token.
|
||||
- **FR-001**: The RSVP bottom sheet MUST offer an attending flow only: name field (required, max 100 characters) + submit. There is no explicit "not attending" option — the guest simply closes the sheet.
|
||||
- **FR-002**: Submission MUST be blocked if the name is blank or exceeds 100 characters.
|
||||
- **FR-003**: If a prior RSVP for this event exists in localStorage (rsvpToken present), the sticky bottom bar MUST show the guest's RSVP status instead of the initial CTA. Editing the RSVP (name change, withdrawal) is out of scope for this spec.
|
||||
- **FR-004**: On successful attending RSVP submission, the server MUST persist the RSVP associated with the event and return an rsvpToken.
|
||||
- **FR-005**: On successful RSVP submission, the client MUST store the guest's name and the server-returned rsvpToken in localStorage, keyed by event token.
|
||||
- **FR-006**: On successful RSVP submission, the client MUST store the event token, event title, and event date in localStorage (to support the local event overview, US-7).
|
||||
- **FR-007**: If a prior RSVP for this event exists in localStorage, the form MUST pre-fill with the stored choice and name on page load.
|
||||
- **FR-008**: Re-submitting an RSVP from a device that has an existing server-side entry for this event MUST update the existing entry, not create a new one.
|
||||
- **FR-013**: The event page MUST present the event fullscreen with a sticky bottom bar containing the RSVP call-to-action. Tapping the CTA MUST open a bottom sheet with the RSVP form.
|
||||
- **FR-014**: After successful RSVP submission, the bottom sheet MUST close and the sticky bar MUST transition to showing the RSVP status.
|
||||
- **FR-009**: The RSVP form MUST NOT be shown and the server MUST reject RSVP submissions after the event's expiry date has passed.
|
||||
- **FR-010**: The RSVP form MUST NOT be shown and the server MUST reject RSVP submissions if the event has been cancelled [enforcement deferred until US-18 is implemented].
|
||||
- **FR-011**: RSVP submission MUST NOT require an account, login, or any personal data beyond the optionally entered name.
|
||||
- **FR-011**: RSVP submission MUST NOT require an account, login, or any personal data beyond the entered name.
|
||||
- **FR-012**: No personal data or IP address MUST be logged on the server when processing an RSVP.
|
||||
- **FR-015**: The event page MUST show only the attendee count publicly. The full attendee name list is out of scope (see 009-guest-list).
|
||||
|
||||
### Key Entities
|
||||
|
||||
- **RSVP**: Represents a guest's attendance declaration. Attributes: event token reference, attending status (boolean), optional name, creation/update timestamp. The server-side identity key for deduplication is the combination of event token and a device-bound identifier [NEEDS EXPANSION: deduplication mechanism to be defined during implementation].
|
||||
- **RSVP**: Represents a guest's attendance declaration. Attributes: rsvpToken (server-generated UUID, returned to client), event reference, name (required), creation timestamp. Existence of an entry implies attendance — no `attending` boolean. The rsvpToken is returned to the client for future use (editing/withdrawal in a later spec). Duplicates from lost localStorage or different devices are accepted as a privacy trade-off.
|
||||
- **RsvpToken**: A server-generated, event-scoped UUID identifying a single RSVP entry. Modeled as a distinct Java record type (alongside EventToken and OrganizerToken). Stored client-side in localStorage per event.
|
||||
|
||||
## Success Criteria
|
||||
|
||||
### Measurable Outcomes
|
||||
|
||||
- **SC-001**: A guest can submit an RSVP (attending with name, or not attending without name) from the event page without an account.
|
||||
- **SC-002**: Submitting an RSVP from the same device twice results in exactly one server-side RSVP entry for that guest (no duplicates).
|
||||
- **SC-001**: A guest can submit an RSVP (name + submit) from the event page without an account.
|
||||
- **SC-002**: After submitting, the sticky bar shows the guest's RSVP status (not the CTA).
|
||||
- **SC-003**: After submitting an RSVP, the local event overview (US-7) can display the event without a server request (event token, title, and date are in localStorage).
|
||||
- **SC-004**: The RSVP form is not shown on expired events, and direct server submissions for expired events are rejected.
|
||||
- **SC-005**: No name, IP address, or personal data beyond the submitted name is stored or logged by the server in connection with an RSVP.
|
||||
|
||||
190
specs/008-rsvp/tasks.md
Normal file
190
specs/008-rsvp/tasks.md
Normal file
@@ -0,0 +1,190 @@
|
||||
# Tasks: RSVP to an Event
|
||||
|
||||
**Input**: Design documents from `/specs/008-rsvp/`
|
||||
**Prerequisites**: plan.md, spec.md, data-model.md, contracts/create-rsvp.yaml, research.md, quickstart.md
|
||||
|
||||
**Tests**: Included — constitution mandates Test-Driven Methodology (tests before implementation).
|
||||
|
||||
**Organization**: Tasks grouped by user story for independent implementation and testing.
|
||||
|
||||
## Format: `[ID] [P?] [Story] Description`
|
||||
|
||||
- **[P]**: Can run in parallel (different files, no dependencies)
|
||||
- **[Story]**: Which user story this task belongs to (e.g., US1, US2)
|
||||
- Exact file paths included in descriptions
|
||||
|
||||
## Phase 1: Setup
|
||||
|
||||
**Purpose**: OpenAPI spec and database migration — shared infrastructure for all user stories
|
||||
|
||||
- [x] T001 Update OpenAPI spec with RSVP endpoint, request/response schemas, and `attendeeCount` population in `backend/src/main/resources/openapi/api.yaml`
|
||||
- [x] T002 [P] Create Liquibase migration for rsvps table in `backend/src/main/resources/db/changelog/003-create-rsvps-table.xml`
|
||||
- [x] T003 [P] Include new migration in `backend/src/main/resources/db/changelog/db.changelog-master.xml`
|
||||
|
||||
---
|
||||
|
||||
## Phase 2: Foundational (Blocking Prerequisites)
|
||||
|
||||
**Purpose**: Token value objects and cross-cutting refactoring — MUST complete before user stories
|
||||
|
||||
**Why blocking**: All new RSVP code uses typed tokens. Existing code must be refactored first to avoid mixing raw UUID and typed tokens.
|
||||
|
||||
- [x] T004 [P] Create `EventToken` record in `backend/src/main/java/de/fete/domain/model/EventToken.java`
|
||||
- [x] T005 [P] Create `OrganizerToken` record in `backend/src/main/java/de/fete/domain/model/OrganizerToken.java`
|
||||
- [x] T006 [P] Create `RsvpToken` record in `backend/src/main/java/de/fete/domain/model/RsvpToken.java`
|
||||
- [x] T007 Refactor `Event` domain model to use `EventToken`/`OrganizerToken` in `backend/src/main/java/de/fete/domain/model/Event.java`
|
||||
- [x] T008 Refactor `EventRepository` port to use typed tokens in `backend/src/main/java/de/fete/domain/port/out/EventRepository.java`
|
||||
- [x] T009 Refactor `EventPersistenceAdapter` to map typed tokens in `backend/src/main/java/de/fete/adapter/out/persistence/EventPersistenceAdapter.java`
|
||||
- [x] T010 Refactor `EventService` to use typed tokens in `backend/src/main/java/de/fete/application/service/EventService.java`
|
||||
- [x] T011 Refactor `EventController` to unwrap/wrap typed tokens at API boundary in `backend/src/main/java/de/fete/adapter/in/web/EventController.java`
|
||||
- [x] T012 Update `EventServiceTest` to use typed tokens in `backend/src/test/java/de/fete/application/service/EventServiceTest.java`
|
||||
- [x] T013 Update `EventControllerIntegrationTest` to use typed tokens in `backend/src/test/java/de/fete/adapter/in/web/EventControllerIntegrationTest.java`
|
||||
- [x] T014 Verify all existing tests pass after token refactoring (`cd backend && ./mvnw test`)
|
||||
|
||||
**Checkpoint**: All existing tests green with typed tokens. New RSVP domain work can begin.
|
||||
|
||||
---
|
||||
|
||||
## Phase 3: User Story 1 — Submit an RSVP (Priority: P1) MVP
|
||||
|
||||
**Goal**: A guest can open an active event page, tap the RSVP CTA, enter their name, submit, and see confirmation. Server persists the RSVP and returns an rsvpToken. localStorage stores RSVP data. Attendee count is populated from real data.
|
||||
|
||||
**Independent Test**: Open an event page, submit an RSVP with a name, verify attendee count updates, verify localStorage contains rsvpToken and name.
|
||||
|
||||
### Backend Tests for US1
|
||||
|
||||
- [x] T015 [P] [US1] Write unit tests for `RsvpService` (create RSVP, validation, event-not-found) in `backend/src/test/java/de/fete/application/service/RsvpServiceTest.java`
|
||||
- [x] T016 [P] [US1] Write integration tests for `POST /events/{eventToken}/rsvps` (201 success, 400 validation, 404 not found) in `backend/src/test/java/de/fete/adapter/in/web/EventControllerIntegrationTest.java`
|
||||
|
||||
### Backend Implementation for US1
|
||||
|
||||
- [x] T017 [P] [US1] Create `Rsvp` domain entity in `backend/src/main/java/de/fete/domain/model/Rsvp.java`
|
||||
- [x] T018 [P] [US1] Create `CreateRsvpUseCase` inbound port in `backend/src/main/java/de/fete/domain/port/in/CreateRsvpUseCase.java`
|
||||
- [x] T019 [P] [US1] Create `RsvpRepository` outbound port with `save()` and `countByEventId()` in `backend/src/main/java/de/fete/domain/port/out/RsvpRepository.java`
|
||||
- [x] T020 [P] [US1] Create `RsvpJpaEntity` in `backend/src/main/java/de/fete/adapter/out/persistence/RsvpJpaEntity.java`
|
||||
- [x] T021 [P] [US1] Create `RsvpJpaRepository` (Spring Data) in `backend/src/main/java/de/fete/adapter/out/persistence/RsvpJpaRepository.java`
|
||||
- [x] T022 [US1] Implement `RsvpPersistenceAdapter` in `backend/src/main/java/de/fete/adapter/out/persistence/RsvpPersistenceAdapter.java`
|
||||
- [x] T023 [US1] Implement `RsvpService` (create RSVP logic, validate event exists) in `backend/src/main/java/de/fete/application/service/RsvpService.java`
|
||||
- [x] T024 [US1] Add `createRsvp()` method to `EventController` in `backend/src/main/java/de/fete/adapter/in/web/EventController.java`
|
||||
- [x] T025 [US1] Wire attendee count: add `countByEventId()` call to GET event flow, populate `attendeeCount` in response in `backend/src/main/java/de/fete/adapter/in/web/EventController.java`
|
||||
- [x] T026 [US1] Verify backend tests pass (`cd backend && ./mvnw test`)
|
||||
|
||||
### Frontend Tests for US1
|
||||
|
||||
- [ ] T027 [P] [US1] Write unit tests for `BottomSheet` component in `frontend/src/components/__tests__/BottomSheet.spec.ts`
|
||||
- [ ] T028 [P] [US1] Write unit tests for `RsvpBar` component in `frontend/src/components/__tests__/RsvpBar.spec.ts`
|
||||
- [ ] T029 [P] [US1] Update unit tests for `useEventStorage` composable (rsvpToken/rsvpName fields) in `frontend/src/composables/__tests__/useEventStorage.spec.ts`
|
||||
|
||||
### Frontend Implementation for US1
|
||||
|
||||
- [ ] T030 [US1] Regenerate TypeScript types from updated OpenAPI spec (`frontend/src/api/schema.d.ts`)
|
||||
- [ ] T031 [P] [US1] Extend `useEventStorage` composable with `rsvpToken` and `rsvpName` fields in `frontend/src/composables/useEventStorage.ts`
|
||||
- [ ] T032 [P] [US1] Create `BottomSheet.vue` component (slide-up, backdrop, focus trap, ESC close, aria-modal) in `frontend/src/components/BottomSheet.vue`
|
||||
- [ ] T033 [P] [US1] Create `RsvpBar.vue` sticky bottom bar (CTA state + status state) in `frontend/src/components/RsvpBar.vue`
|
||||
- [ ] T034 [US1] Integrate `RsvpBar` + `BottomSheet` + RSVP form into `EventDetailView`, including error state when server is unreachable, in `frontend/src/views/EventDetailView.vue`
|
||||
- [ ] T035 [US1] Add bottom sheet and sticky bar styles to `frontend/src/assets/main.css`
|
||||
- [ ] T036 [US1] Update `EventDetailView` unit tests for RSVP integration in `frontend/src/views/__tests__/EventDetailView.spec.ts`
|
||||
|
||||
### E2E Tests for US1
|
||||
|
||||
- [ ] T037 [US1] Write E2E tests: RSVP submission flow, localStorage verification, attendee count update in `frontend/e2e/event-rsvp.spec.ts`
|
||||
|
||||
**Checkpoint**: US1 complete — guest can submit RSVP, see confirmation, attendee count populated. All backend + frontend tests green.
|
||||
|
||||
---
|
||||
|
||||
## Phase 4: User Story 2 — RSVP Blocked on Expired Events (Priority: P2)
|
||||
|
||||
**Goal**: Expired events hide the RSVP form and the server rejects RSVP submissions with 409 Conflict.
|
||||
|
||||
**Independent Test**: Attempt to RSVP to an expired event — verify form is hidden client-side and server returns 409.
|
||||
|
||||
### Tests for US2
|
||||
|
||||
- [ ] T038 [P] [US2] Write backend test for expired event rejection (409) in `backend/src/test/java/de/fete/application/service/RsvpServiceTest.java`
|
||||
- [ ] T039 [P] [US2] Write integration test for `POST /events/{eventToken}/rsvps` returning 409 on expired event in `backend/src/test/java/de/fete/adapter/in/web/EventControllerIntegrationTest.java`
|
||||
|
||||
### Implementation for US2
|
||||
|
||||
- [ ] T040 [US2] Add expiry check to `RsvpService.createRsvp()` — throw `EventExpiredException` when event date has passed in `backend/src/main/java/de/fete/application/service/RsvpService.java`
|
||||
- [ ] T041 [US2] Handle `EventExpiredException` in `GlobalExceptionHandler` — return 409 Conflict in `backend/src/main/java/de/fete/adapter/in/web/GlobalExceptionHandler.java`
|
||||
- [ ] T042 [US2] Hide RSVP bar/form on expired events in `EventDetailView` (check `expired` field from API response) in `frontend/src/views/EventDetailView.vue`
|
||||
- [ ] T043 [US2] Write E2E test for expired event: verify RSVP form hidden, direct API call returns 409 in `frontend/e2e/event-rsvp.spec.ts`
|
||||
- [ ] T044 [US2] Verify all tests pass (`cd backend && ./mvnw test && cd ../frontend && npm run test:unit`)
|
||||
|
||||
**Checkpoint**: US2 complete — expired events block RSVPs client-side and server-side.
|
||||
|
||||
---
|
||||
|
||||
## Phase 5: Polish & Cross-Cutting Concerns
|
||||
|
||||
**Purpose**: Final verification across all stories
|
||||
|
||||
- [ ] T045 Run full backend verify (`cd backend && ./mvnw verify`)
|
||||
- [ ] T046 Run frontend build and type-check (`cd frontend && npm run build`)
|
||||
- [ ] T047 Run all E2E tests (`cd frontend && npx playwright test`)
|
||||
- [ ] T048 Visual verification of RSVP flow using `browser-interactive-testing` skill
|
||||
|
||||
---
|
||||
|
||||
## Dependencies & Execution Order
|
||||
|
||||
### Phase Dependencies
|
||||
|
||||
- **Setup (Phase 1)**: No dependencies — can start immediately
|
||||
- **Foundational (Phase 2)**: Depends on T001 (OpenAPI spec) for schema awareness; T002-T003 (migration) independent
|
||||
- **US1 (Phase 3)**: Depends on Phase 2 completion (typed tokens in place)
|
||||
- **US2 (Phase 4)**: Depends on Phase 3 (RSVP creation must exist before expiry guard)
|
||||
- **Polish (Phase 5)**: Depends on all user stories complete
|
||||
|
||||
### User Story Dependencies
|
||||
|
||||
- **US1 (P1)**: Can start after Phase 2 — no dependency on US2
|
||||
- **US2 (P2)**: Depends on US1 (the RSVP endpoint and form must exist before adding the expiry guard)
|
||||
|
||||
### Within Each User Story
|
||||
|
||||
- Tests MUST be written first and FAIL before implementation
|
||||
- Domain model/ports before persistence adapters
|
||||
- Persistence before services
|
||||
- Services before controllers
|
||||
- Backend before frontend (API must exist for frontend to consume)
|
||||
- Frontend components before view integration
|
||||
- Unit tests before E2E tests
|
||||
|
||||
### Parallel Opportunities
|
||||
|
||||
**Phase 1**: T002 and T003 can run in parallel with T001
|
||||
**Phase 2**: T004, T005, T006 in parallel; then T007-T013 sequentially (refactoring chain)
|
||||
**Phase 3 Backend**: T015+T016 (tests) in parallel; T017+T018+T019+T020+T021 (domain/ports/JPA) in parallel; then T022→T023→T024→T025 sequential
|
||||
**Phase 3 Frontend**: T027+T028+T029 (tests) in parallel; T031+T032+T033 in parallel; then T034→T035→T036→T037 sequential
|
||||
**Phase 4**: T038+T039 (tests) in parallel; then T040→T041→T042→T043→T044 sequential
|
||||
|
||||
---
|
||||
|
||||
## Implementation Strategy
|
||||
|
||||
### MVP First (User Story 1 Only)
|
||||
|
||||
1. Complete Phase 1: Setup (OpenAPI + migration)
|
||||
2. Complete Phase 2: Foundational (token value objects + refactoring)
|
||||
3. Complete Phase 3: User Story 1 (full RSVP flow)
|
||||
4. **STOP and VALIDATE**: Guest can submit RSVP, see confirmation, attendee count works
|
||||
5. Deploy/demo if ready
|
||||
|
||||
### Incremental Delivery
|
||||
|
||||
1. Setup + Foundational → Token refactoring complete, schema ready
|
||||
2. Add US1 → Full RSVP flow works → Deploy/Demo (MVP!)
|
||||
3. Add US2 → Expired events guarded → Deploy/Demo
|
||||
4. Polish → All tests green, visual verification done
|
||||
|
||||
---
|
||||
|
||||
## Notes
|
||||
|
||||
- Cancelled event guard (FR-010) is deferred until US-18 — NOT included in tasks
|
||||
- No CAPTCHA/rate-limiting per spec (KISS, privacy-first)
|
||||
- RSVP editing/withdrawal deferred to separate edit-RSVP spec
|
||||
- Frontend uses plain `string` for tokens (no branded types) per clarification
|
||||
- Backend uses typed records (`EventToken`, `OrganizerToken`, `RsvpToken`) per clarification
|
||||
@@ -1,63 +0,0 @@
|
||||
# Feature Specification: Manage Guest List as Organizer
|
||||
|
||||
**Feature**: `009-guest-list`
|
||||
**Created**: 2026-03-06
|
||||
**Status**: Draft
|
||||
**Source**: Migrated from spec/userstories.md
|
||||
|
||||
## User Scenarios & Testing
|
||||
|
||||
### User Story 1 - View and manage RSVPs (Priority: P1)
|
||||
|
||||
As an event organizer, I want to view all RSVPs for my event and remove individual entries if needed, so that I have an accurate overview of attendance and can moderate erroneous or spam entries.
|
||||
|
||||
The organizer view is accessible from the event page when a valid organizer token for that event is present in localStorage. When no organizer token is present, no organizer-specific UI is shown. The organizer can see each RSVP entry with name and attending status, and can permanently delete any entry.
|
||||
|
||||
**Why this priority**: Core organizer capability — without it, the organizer has no way to manage erroneous or spam RSVP entries. The public attendee list is only trustworthy if the organizer can moderate it.
|
||||
|
||||
**Independent Test**: Can be tested by creating an event (obtaining an organizer token), submitting several RSVPs via the RSVP form, then opening the organizer view to verify the list is displayed and deletion works.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** an organizer token for an event is present in localStorage, **When** the organizer opens the event page, **Then** an organizer view link or section is visible that is not shown to guests without the token.
|
||||
2. **Given** the organizer view is open, **When** the page loads, **Then** all RSVPs for the event are listed, each showing the entry's name and attending status.
|
||||
3. **Given** the organizer view is open with at least one RSVP entry, **When** the organizer deletes an entry, **Then** the entry is permanently removed from the server and immediately disappears from the attendee list on the public event page.
|
||||
4. **Given** a visitor without an organizer token in localStorage opens the event page, **When** the page renders, **Then** no organizer-specific UI (link, button, or organizer view) is visible.
|
||||
5. **Given** the organizer view is open, **When** the organizer attempts to access it via a guessable URL without the organizer token in localStorage, **Then** organizer access is denied — it requires the organizer token established during event creation.
|
||||
6. **Given** the organizer has a valid organizer token in localStorage, **When** the organizer accesses the organizer view, **Then** no additional authentication step beyond the localStorage token is required.
|
||||
|
||||
---
|
||||
|
||||
### Edge Cases
|
||||
|
||||
- What happens when the organizer token is present in localStorage but the event no longer exists on the server?
|
||||
- How does the system handle a deletion request when the organizer token is invalid or has been cleared from localStorage mid-session?
|
||||
- What if all RSVPs are deleted — does the organizer view show an empty state?
|
||||
|
||||
## Requirements
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-001**: System MUST display the organizer view (guest list management) only when a valid organizer token for that event is present in localStorage.
|
||||
- **FR-002**: System MUST hide all organizer-specific UI (links, buttons, organizer view) from visitors who do not have the organizer token in localStorage.
|
||||
- **FR-003**: Organizer view MUST list all RSVPs for the event, showing each entry's name and attending status.
|
||||
- **FR-004**: Organizer MUST be able to permanently delete any individual RSVP entry from the organizer view.
|
||||
- **FR-005**: System MUST reflect RSVP deletions immediately on the public event page — the attendee list must update without delay.
|
||||
- **FR-006**: Organizer view MUST NOT be accessible via a guessable URL — access requires the organizer token stored in localStorage during event creation (US-1).
|
||||
- **FR-007**: System MUST NOT require any additional authentication step beyond the presence of the organizer token in localStorage.
|
||||
- **FR-008**: Server MUST reject RSVP deletion requests that do not include a valid organizer token.
|
||||
|
||||
### Key Entities
|
||||
|
||||
- **RSVP**: An entry submitted by a guest (US-3). Attributes: event association, guest name, attending status. The organizer can delete individual entries.
|
||||
- **Organizer token**: A secret UUID stored in localStorage on the device where the event was created (US-1). Grants organizer access to the guest list management view.
|
||||
|
||||
## Success Criteria
|
||||
|
||||
### Measurable Outcomes
|
||||
|
||||
- **SC-001**: An organizer can view the complete guest list for their event from the event page without navigating away to a separate URL.
|
||||
- **SC-002**: An organizer can delete any RSVP entry and the deletion is reflected on the public event page within the same page interaction (no reload required).
|
||||
- **SC-003**: A visitor without the organizer token in localStorage sees no organizer UI at all — zero organizer-specific elements rendered.
|
||||
- **SC-004**: The organizer view is not reachable by guessing or constructing a URL — it requires the in-memory/localStorage token to render.
|
||||
- **SC-005**: No additional login, account, or authentication beyond the organizer token is required to manage the guest list.
|
||||
35
specs/009-list-events/checklists/requirements.md
Normal file
35
specs/009-list-events/checklists/requirements.md
Normal file
@@ -0,0 +1,35 @@
|
||||
# Specification Quality Checklist: Event List on Home Page
|
||||
|
||||
**Purpose**: Validate specification completeness and quality before proceeding to planning
|
||||
**Created**: 2026-03-08
|
||||
**Feature**: [spec.md](../spec.md)
|
||||
|
||||
## Content Quality
|
||||
|
||||
- [x] No implementation details (languages, frameworks, APIs)
|
||||
- [x] Focused on user value and business needs
|
||||
- [x] Written for non-technical stakeholders
|
||||
- [x] All mandatory sections completed
|
||||
|
||||
## Requirement Completeness
|
||||
|
||||
- [x] No [NEEDS CLARIFICATION] markers remain
|
||||
- [x] Requirements are testable and unambiguous
|
||||
- [x] Success criteria are measurable
|
||||
- [x] Success criteria are technology-agnostic (no implementation details)
|
||||
- [x] All acceptance scenarios are defined
|
||||
- [x] Edge cases are identified
|
||||
- [x] Scope is clearly bounded
|
||||
- [x] Dependencies and assumptions identified
|
||||
|
||||
## Feature Readiness
|
||||
|
||||
- [x] All functional requirements have clear acceptance criteria
|
||||
- [x] User scenarios cover primary flows
|
||||
- [x] Feature meets measurable outcomes defined in Success Criteria
|
||||
- [x] No implementation details leak into specification
|
||||
|
||||
## Notes
|
||||
|
||||
- All items pass validation. Spec is ready for `/speckit.clarify` or `/speckit.plan`.
|
||||
- Assumptions section documents that no backend changes are needed — this is a frontend-only feature using existing localStorage data.
|
||||
99
specs/009-list-events/data-model.md
Normal file
99
specs/009-list-events/data-model.md
Normal file
@@ -0,0 +1,99 @@
|
||||
# Data Model: Event List on Home Page
|
||||
|
||||
**Feature**: 009-list-events | **Date**: 2026-03-08
|
||||
|
||||
## Entities
|
||||
|
||||
### StoredEvent (existing — no changes)
|
||||
|
||||
The `StoredEvent` interface in `frontend/src/composables/useEventStorage.ts` already contains all fields needed for the event list feature.
|
||||
|
||||
```typescript
|
||||
interface StoredEvent {
|
||||
eventToken: string // Required — UUID, used for navigation
|
||||
organizerToken?: string // Present if user created this event
|
||||
title: string // Required — displayed on card
|
||||
dateTime: string // Required — ISO 8601, used for sorting + relative time
|
||||
expiryDate: string // Stored but not displayed in list view
|
||||
rsvpToken?: string // Present if user RSVP'd to this event
|
||||
rsvpName?: string // User's name at RSVP time
|
||||
}
|
||||
```
|
||||
|
||||
### Validation Rules
|
||||
|
||||
An event entry is considered **valid** for display if all of:
|
||||
- `eventToken` is a non-empty string
|
||||
- `title` is a non-empty string
|
||||
- `dateTime` is a non-empty string that parses to a valid `Date`
|
||||
|
||||
Invalid entries are silently excluded from the list (FR-010).
|
||||
|
||||
### Derived Properties (computed at render time)
|
||||
|
||||
| Property | Derivation |
|
||||
|----------|-----------|
|
||||
| `isPast` | `new Date(dateTime) < new Date()` |
|
||||
| `isOrganizer` | `organizerToken !== undefined` |
|
||||
| `isAttendee` | `rsvpToken !== undefined && organizerToken === undefined` |
|
||||
| `relativeTime` | `Intl.RelativeTimeFormat` applied to `dateTime` vs now |
|
||||
| `detailRoute` | `/events/${eventToken}` |
|
||||
|
||||
### Sorting Order
|
||||
|
||||
1. **Upcoming events** (`dateTime >= now`): ascending by `dateTime` (soonest first)
|
||||
2. **Past events** (`dateTime < now`): descending by `dateTime` (most recently passed first)
|
||||
|
||||
### Composable Extension
|
||||
|
||||
The `useEventStorage` composable needs one new function:
|
||||
|
||||
```typescript
|
||||
function removeEvent(eventToken: string): void {
|
||||
const events = readEvents().filter((e) => e.eventToken !== eventToken)
|
||||
writeEvents(events)
|
||||
}
|
||||
```
|
||||
|
||||
Returned alongside existing functions from `useEventStorage()`.
|
||||
|
||||
## State Transitions
|
||||
|
||||
```
|
||||
localStorage read
|
||||
│
|
||||
▼
|
||||
Parse JSON ──(error)──► empty array
|
||||
│
|
||||
▼
|
||||
Validate entries ──(invalid)──► silently excluded
|
||||
│
|
||||
▼
|
||||
Split: upcoming / past
|
||||
│
|
||||
▼
|
||||
Sort each group
|
||||
│
|
||||
▼
|
||||
Concatenate ──► rendered list
|
||||
```
|
||||
|
||||
### Remove Event Flow
|
||||
|
||||
```
|
||||
User taps delete icon / swipes left
|
||||
│
|
||||
▼
|
||||
ConfirmDialog opens
|
||||
│
|
||||
┌────┴────┐
|
||||
│ Cancel │ Confirm
|
||||
│ │ │
|
||||
│ ▼ ▼
|
||||
│ removeEvent(token)
|
||||
│ │
|
||||
│ ▼
|
||||
│ Event removed from localStorage
|
||||
│ List re-renders (event disappears)
|
||||
└────────────────────────────────┘
|
||||
```
|
||||
86
specs/009-list-events/plan.md
Normal file
86
specs/009-list-events/plan.md
Normal file
@@ -0,0 +1,86 @@
|
||||
# Implementation Plan: Event List on Home Page
|
||||
|
||||
**Branch**: `009-list-events` | **Date**: 2026-03-08 | **Spec**: `specs/009-list-events/spec.md`
|
||||
**Input**: Feature specification from `/specs/009-list-events/spec.md`
|
||||
|
||||
## Summary
|
||||
|
||||
Transform the home page from a static empty-state placeholder into a dynamic event list that shows all events stored in the browser's localStorage. Each event card displays title, relative time, and role indicator (organizer/attendee). Events are sorted chronologically (upcoming first), past events appear faded, and users can remove events via delete icon or swipe gesture. A FAB provides persistent access to event creation.
|
||||
|
||||
This is a **frontend-only** feature — no backend or API changes required. The existing `useEventStorage` composable already provides all necessary data access.
|
||||
|
||||
## Technical Context
|
||||
|
||||
**Language/Version**: TypeScript 5.9, Vue 3.5
|
||||
**Primary Dependencies**: Vue 3, Vue Router 5, Vite
|
||||
**Storage**: Browser localStorage via `useEventStorage` composable
|
||||
**Testing**: Vitest (unit), Playwright + MSW (E2E)
|
||||
**Target Platform**: Mobile-first PWA (centered 480px column on desktop)
|
||||
**Project Type**: Web application (frontend-only changes)
|
||||
**Performance Goals**: Event list renders within 1 second (SC-001) — trivial given localStorage read
|
||||
**Constraints**: No external dependencies, no tracking, WCAG AA, keyboard navigable
|
||||
**Scale/Scope**: Typically <50 events in localStorage; no pagination needed
|
||||
|
||||
## Constitution Check
|
||||
|
||||
*GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.*
|
||||
|
||||
| Principle | Status | Notes |
|
||||
|-----------|--------|-------|
|
||||
| I. Privacy by Design | ✅ PASS | Purely client-side. No data leaves the browser. No analytics. |
|
||||
| II. Test-Driven Methodology | ✅ PASS | Unit tests for composable, E2E for each user story. TDD enforced. |
|
||||
| III. API-First Development | ✅ N/A | No API changes — this feature reads only from localStorage. |
|
||||
| IV. Simplicity & Quality | ✅ PASS | Minimal approach: extend existing composable + new components. No over-engineering. |
|
||||
| V. Dependency Discipline | ✅ PASS | No new dependencies. Swipe gesture implemented with native Touch API. Relative time via built-in `Intl.RelativeTimeFormat`. |
|
||||
| VI. Accessibility | ✅ PASS | Semantic list markup, ARIA labels, keyboard navigation, WCAG AA contrast on faded past events. |
|
||||
|
||||
**Gate result: PASS** — no violations.
|
||||
|
||||
## Project Structure
|
||||
|
||||
### Documentation (this feature)
|
||||
|
||||
```text
|
||||
specs/009-list-events/
|
||||
├── plan.md # This file
|
||||
├── spec.md # Feature specification
|
||||
├── research.md # Phase 0 output
|
||||
├── data-model.md # Phase 1 output
|
||||
└── tasks.md # Phase 2 output (/speckit.tasks command)
|
||||
```
|
||||
|
||||
### Source Code (repository root)
|
||||
|
||||
```text
|
||||
frontend/
|
||||
├── src/
|
||||
│ ├── composables/
|
||||
│ │ ├── useEventStorage.ts # MODIFY: add removeEvent()
|
||||
│ │ ├── useRelativeTime.ts # NEW: Intl.RelativeTimeFormat wrapper
|
||||
│ │ └── __tests__/
|
||||
│ │ ├── useEventStorage.spec.ts # MODIFY: add removeEvent tests
|
||||
│ │ └── useRelativeTime.spec.ts # NEW: relative time formatting tests
|
||||
│ ├── components/
|
||||
│ │ ├── EventCard.vue # NEW: individual event list item
|
||||
│ │ ├── EventList.vue # NEW: sorted event list container
|
||||
│ │ ├── EmptyState.vue # NEW: extracted empty state
|
||||
│ │ ├── CreateEventFab.vue # NEW: floating action button
|
||||
│ │ ├── ConfirmDialog.vue # NEW: reusable confirmation prompt
|
||||
│ │ └── __tests__/
|
||||
│ │ ├── EventCard.spec.ts # NEW
|
||||
│ │ ├── EventList.spec.ts # NEW
|
||||
│ │ ├── EmptyState.spec.ts # NEW
|
||||
│ │ └── ConfirmDialog.spec.ts # NEW
|
||||
│ ├── views/
|
||||
│ │ └── HomeView.vue # MODIFY: compose list/empty/fab
|
||||
│ └── assets/
|
||||
│ └── main.css # MODIFY: add event card, faded, fab styles
|
||||
└── e2e/
|
||||
└── home-events.spec.ts # NEW: E2E tests for all user stories
|
||||
```
|
||||
|
||||
**Structure Decision**: Frontend-only changes. New components in `components/`, composable extensions in `composables/`, styles in existing `main.css`. No backend changes.
|
||||
|
||||
## Complexity Tracking
|
||||
|
||||
No constitution violations — this section is intentionally empty.
|
||||
110
specs/009-list-events/research.md
Normal file
110
specs/009-list-events/research.md
Normal file
@@ -0,0 +1,110 @@
|
||||
# Research: Event List on Home Page
|
||||
|
||||
**Feature**: 009-list-events | **Date**: 2026-03-08
|
||||
|
||||
## Research Questions
|
||||
|
||||
### 1. Relative Time Formatting with `Intl.RelativeTimeFormat`
|
||||
|
||||
**Decision**: Use the built-in `Intl.RelativeTimeFormat` API directly — no library needed.
|
||||
|
||||
**Rationale**: The API is supported in all modern browsers (97%+ coverage). It handles locale-aware output natively (e.g., "in 3 days", "vor 2 Tagen" for German). The spec requires exactly this (FR-002).
|
||||
|
||||
**Implementation approach**: Create a `useRelativeTime` composable that:
|
||||
1. Takes a date string (ISO 8601) and computes the difference from `now`
|
||||
2. Selects the appropriate unit (seconds → minutes → hours → days → weeks → months → years)
|
||||
3. Returns a formatted string via `Intl.RelativeTimeFormat(navigator.language, { numeric: 'auto' })`
|
||||
4. Exposes a reactive `label` that updates (optional — can be static since the list re-reads on mount)
|
||||
|
||||
**Alternatives considered**:
|
||||
- `date-fns/formatDistance`: Would add a dependency for something the platform already does. Rejected per Principle V.
|
||||
- `dayjs/relativeTime`: Same reasoning — unnecessary dependency.
|
||||
|
||||
### 2. Swipe-to-Delete Gesture (FR-006b)
|
||||
|
||||
**Decision**: Implement with native Touch API (`touchstart`, `touchmove`, `touchend`) — no gesture library.
|
||||
|
||||
**Rationale**: The gesture is simple (horizontal swipe on a single element). A library like Hammer.js or @vueuse/gesture would be overkill for one swipe direction on one component type. Per Principle V, dependencies must provide substantial value.
|
||||
|
||||
**Implementation approach**:
|
||||
1. Track `touchstart` X position on the event card
|
||||
2. On `touchmove`, calculate delta-X; if leftward and exceeds threshold (~80px), reveal delete action
|
||||
3. On `touchend`, either snap back or trigger confirmation
|
||||
4. CSS `transform: translateX()` with `transition` for smooth animation
|
||||
5. Desktop users use the visible delete icon (no swipe needed)
|
||||
|
||||
**Alternatives considered**:
|
||||
- `@vueuse/gesture`: Wraps Hammer.js, adds ~15KB. Rejected — too heavy for one gesture.
|
||||
- CSS `scroll-snap` trick: Clever but brittle and poor accessibility. Rejected.
|
||||
|
||||
### 3. Past Event Visual Fading (FR-009)
|
||||
|
||||
**Decision**: Use CSS `opacity` reduction + `filter: saturate()` for faded appearance.
|
||||
|
||||
**Rationale**: The spec says "subtle reduction in contrast and saturation" — not a blunt grey-out. Combining `opacity: 0.6` with `filter: saturate(0.5)` achieves this while keeping text readable. Must verify WCAG AA contrast on the faded state.
|
||||
|
||||
**Implementation approach**:
|
||||
- Add a `.event-card--past` modifier class
|
||||
- Apply `opacity: 0.55; filter: saturate(0.4)` (tune exact values for WCAG AA)
|
||||
- Keep `pointer-events: auto` and normal hover/focus styles so the card remains interactive
|
||||
- The card still navigates to the event detail page on click
|
||||
|
||||
**Contrast verification**: The card text (`#1C1C1E` on `#FFFFFF`) has a contrast ratio of ~17:1. At `opacity: 0.55`, effective contrast drops to ~9:1, which still passes WCAG AA (4.5:1 minimum). Safe.
|
||||
|
||||
### 4. Confirmation Dialog (FR-007)
|
||||
|
||||
**Decision**: Custom modal component (reusing the existing `BottomSheet.vue` pattern) rather than `window.confirm()`.
|
||||
|
||||
**Rationale**: `window.confirm()` is blocking, non-stylable, and inconsistent across browsers. A custom dialog matches the app's design system and provides a better UX. The existing `BottomSheet.vue` already handles teleportation, focus trapping, and Escape-key dismissal — the confirm dialog can reuse this or follow the same pattern.
|
||||
|
||||
**Implementation approach**:
|
||||
- Create a `ConfirmDialog.vue` component
|
||||
- Props: `open`, `title`, `message`, `confirmLabel`, `cancelLabel`
|
||||
- Emits: `confirm`, `cancel`
|
||||
- Uses the same teleport-to-body pattern as `BottomSheet.vue`
|
||||
- Focus trapping and keyboard navigation (Tab, Escape, Enter)
|
||||
|
||||
### 5. localStorage Validation (FR-010)
|
||||
|
||||
**Decision**: Validate entries during read — filter out invalid events silently.
|
||||
|
||||
**Rationale**: The spec says "silently excluded from the list." The `readEvents()` function already handles parse errors with a try/catch. We need to add field-level validation: an event is valid only if it has `eventToken`, `title`, and `dateTime` (all non-empty strings).
|
||||
|
||||
**Implementation approach**:
|
||||
- Add a `isValidStoredEvent(e: unknown): e is StoredEvent` type guard
|
||||
- Apply it in `getStoredEvents()` as a filter
|
||||
- Invalid entries remain in localStorage (no destructive cleanup) but are not displayed
|
||||
|
||||
### 6. FAB Placement (FR-011)
|
||||
|
||||
**Decision**: Fixed-position button at bottom-right with safe-area padding.
|
||||
|
||||
**Rationale**: Standard Material Design pattern for primary actions. The existing `RsvpBar.vue` already uses `padding-bottom: env(safe-area-inset-bottom)` for mobile notch avoidance — reuse the same approach.
|
||||
|
||||
**Implementation approach**:
|
||||
- `position: fixed; bottom: calc(1.2rem + env(safe-area-inset-bottom)); right: 1.2rem`
|
||||
- Circular button with `+` icon, accent color background
|
||||
- `z-index` above content, shadow for elevation
|
||||
- Navigates to `/create` on click
|
||||
|
||||
### 7. Event Sorting (FR-004)
|
||||
|
||||
**Decision**: Sort in-memory after reading from localStorage.
|
||||
|
||||
**Rationale**: The list is small (<100 events typically). Sorting on every render is negligible. Sort by `dateTime` ascending (nearest upcoming first), then past events after.
|
||||
|
||||
**Implementation approach**:
|
||||
- Split events into `upcoming` (dateTime >= now) and `past` (dateTime < now)
|
||||
- Sort upcoming ascending (soonest first), past descending (most recent past first)
|
||||
- Concatenate: `[...upcoming, ...past]`
|
||||
|
||||
### 8. Role Distinction (FR-008 / US-5)
|
||||
|
||||
**Decision**: Small badge/label on the event card indicating "Organizer" or "Attendee."
|
||||
|
||||
**Rationale**: The data is already available — `organizerToken` present means organizer, `rsvpToken` present (without `organizerToken`) means attendee. A subtle text badge is sufficient; no need for icons or colors.
|
||||
|
||||
**Implementation approach**:
|
||||
- If `organizerToken` is set → show "Organizer" badge (accent-colored)
|
||||
- If `rsvpToken` is set (no `organizerToken`) → show "Attendee" badge (muted)
|
||||
- If neither → show no badge (edge case: event stored but no role — could happen with manual localStorage manipulation)
|
||||
145
specs/009-list-events/spec.md
Normal file
145
specs/009-list-events/spec.md
Normal file
@@ -0,0 +1,145 @@
|
||||
# Feature Specification: Event List on Home Page
|
||||
|
||||
**Feature Branch**: `009-list-events`
|
||||
**Created**: 2026-03-08
|
||||
**Status**: Draft
|
||||
**Input**: User description: "man kann auf der hauptseite eine liste an events sehen, sofern sie im localstorage gespeichert sind"
|
||||
|
||||
## User Scenarios & Testing *(mandatory)*
|
||||
|
||||
### User Story 1 - View My Events (Priority: P1)
|
||||
|
||||
As a returning user, I want to see a list of events I have previously created or interacted with (RSVP'd to) on the home page, so I can quickly navigate back to them without needing to remember or bookmark individual event links.
|
||||
|
||||
The home page displays all events stored in the browser's local storage. Each event entry shows the event title and date/time. Tapping an event navigates to its detail page.
|
||||
|
||||
**Why this priority**: This is the core value of the feature — without the list, the home page remains a dead end for returning users.
|
||||
|
||||
**Independent Test**: Can be fully tested by creating an event (or simulating localStorage entries), returning to the home page, and verifying all stored events appear in a list with correct titles and dates.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** the user has 3 events stored in localStorage, **When** they visit the home page, **Then** all 3 events are displayed in a list showing title and date/time for each.
|
||||
2. **Given** the user has events stored in localStorage, **When** they tap on an event in the list, **Then** they are navigated to the event detail page (`/events/:eventToken`).
|
||||
3. **Given** the user has events stored in localStorage, **When** they visit the home page, **Then** events are sorted by date/time (nearest upcoming event first, past events last).
|
||||
|
||||
---
|
||||
|
||||
### User Story 2 - Empty State (Priority: P2)
|
||||
|
||||
As a new user with no stored events, I see an inviting empty state on the home page that encourages me to create my first event or explains how to get started.
|
||||
|
||||
**Why this priority**: First-time users need clear guidance. The empty state is the first impression for new users.
|
||||
|
||||
**Independent Test**: Can be tested by clearing localStorage and visiting the home page — the empty state message and "Create Event" call-to-action should be visible.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** no events are stored in localStorage, **When** the user visits the home page, **Then** an empty state message is displayed (e.g., "No events yet") with a prominent "Create Event" button.
|
||||
2. **Given** the user has at least one event stored, **When** they visit the home page, **Then** the empty state message is not shown — the event list is displayed instead.
|
||||
|
||||
---
|
||||
|
||||
### User Story 3 - Remove Event from List (Priority: P3)
|
||||
|
||||
As a user, I want to remove an event from my personal list so I can keep my home page tidy and only show events I still care about.
|
||||
|
||||
**Why this priority**: Housekeeping capability. Without removal, the list grows indefinitely and becomes cluttered over time.
|
||||
|
||||
**Independent Test**: Can be tested by having multiple events in localStorage, removing one from the list, and verifying it disappears from the home page while the others remain.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** the user has events in their list, **When** they tap the delete icon on an event card, **Then** a confirmation prompt appears asking if they are sure.
|
||||
1b. **Given** the user has events in their list, **When** they swipe an event card to the left, **Then** a confirmation prompt appears asking if they are sure.
|
||||
2. **Given** the confirmation prompt is shown, **When** the user confirms removal, **Then** the event is removed from localStorage and disappears from the list immediately.
|
||||
3. **Given** the confirmation prompt is shown, **When** the user cancels, **Then** the event remains in the list unchanged.
|
||||
|
||||
---
|
||||
|
||||
### User Story 4 - Past Events Appear Faded (Priority: P2)
|
||||
|
||||
As a user, I want events whose date/time has passed to appear visually faded or muted in the list, so I can immediately focus on upcoming events without past events cluttering my attention.
|
||||
|
||||
The fading should feel modern and polished — not a blunt grey-out, but a subtle reduction in contrast and saturation that makes past events recede visually while remaining readable and tappable.
|
||||
|
||||
**Why this priority**: Without this, past and upcoming events look identical, making the list harder to scan. This is essential for usability once a user has accumulated several events.
|
||||
|
||||
**Independent Test**: Can be tested by having both future and past events in localStorage and verifying that past events display with reduced visual prominence while remaining interactive.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** the user has a past event (dateTime before now) in localStorage, **When** they view the home page, **Then** the event appears with reduced visual prominence (muted colors, lower contrast) compared to upcoming events.
|
||||
2. **Given** the user has a past event in the list, **When** they tap on it, **Then** it still navigates to the event detail page — it remains fully interactive.
|
||||
3. **Given** the user has both past and upcoming events, **When** they view the home page, **Then** upcoming events appear first (full visual prominence), followed by past events (faded), creating a clear visual hierarchy.
|
||||
|
||||
---
|
||||
|
||||
### User Story 5 - Visual Distinction for Event Roles (Priority: P3)
|
||||
|
||||
As a user, I want to see at a glance whether I am the organizer of an event or just an attendee, so I can quickly identify my responsibilities.
|
||||
|
||||
**Why this priority**: Nice-to-have clarity. The data is already available in localStorage (presence of `organizerToken`), so surfacing it improves usability at low effort.
|
||||
|
||||
**Independent Test**: Can be tested by having both created events (with organizerToken) and RSVP'd events (with rsvpToken) in localStorage, and verifying they display different visual indicators.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** the user has a created event (organizerToken present) in localStorage, **When** they view the home page, **Then** the event shows a visual indicator marking them as the organizer (e.g., a badge or label).
|
||||
2. **Given** the user has an event with an RSVP (rsvpToken present, no organizerToken) in localStorage, **When** they view the home page, **Then** the event shows a visual indicator marking them as an attendee.
|
||||
|
||||
---
|
||||
|
||||
### Edge Cases
|
||||
|
||||
- What happens when localStorage data is corrupted or contains invalid entries? Events with missing required fields (eventToken, title, dateTime) are silently excluded from the list.
|
||||
- What happens when localStorage is unavailable (e.g., private browsing with storage disabled)? The empty state is shown with the "Create Event" button — the app remains functional.
|
||||
- What happens when an event's date/time has passed? The event remains in the list but appears visually faded.
|
||||
- What happens when the user has a very large number of stored events (e.g., 50+)? The list scrolls naturally. No pagination is needed at this scale since localStorage entries are lightweight.
|
||||
|
||||
## Requirements *(mandatory)*
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-001**: System MUST display a list of all events stored in the browser's local storage on the home page.
|
||||
- **FR-002**: Each event entry MUST show the event title and the event date/time displayed as a relative time label (e.g., "in 3 days", "yesterday") using `Intl.RelativeTimeFormat`.
|
||||
- **FR-003**: Each event entry MUST be tappable/clickable and navigate to the event detail page (`/events/:eventToken`).
|
||||
- **FR-004**: Events MUST be sorted by date/time with nearest upcoming events first and past events last.
|
||||
- **FR-005**: System MUST display an empty state with a "Create Event" call-to-action when no events are stored.
|
||||
- **FR-006a**: Users MUST be able to remove individual events from their local list via a visible delete icon on each event card (primary mechanism, implemented first).
|
||||
- **FR-006b**: Users MUST be able to remove individual events via swipe-to-delete gesture (secondary mechanism, implemented separately after FR-006a).
|
||||
- **FR-007**: System MUST show a confirmation prompt before removing an event from the list.
|
||||
- **FR-008**: System MUST visually distinguish events where the user is the organizer from events where the user is an attendee.
|
||||
- **FR-009**: System MUST display past events (dateTime before current time) with reduced visual prominence — muted colors and lower contrast — while keeping them readable and interactive.
|
||||
- **FR-010**: System MUST gracefully handle corrupted or incomplete localStorage entries by excluding invalid events from the list.
|
||||
- **FR-011**: The "Create Event" button MUST remain accessible on the home page even when events are listed, implemented as a Floating Action Button (FAB) fixed at the bottom-right corner.
|
||||
|
||||
### Key Entities
|
||||
|
||||
- **Stored Event**: A locally persisted reference to an event the user has interacted with. Contains: event token (unique identifier for navigation), title, date/time, expiry date, and optionally an organizer token (if created by this user) or RSVP token and name (if the user RSVP'd).
|
||||
|
||||
## Success Criteria *(mandatory)*
|
||||
|
||||
### Measurable Outcomes
|
||||
|
||||
- **SC-001**: Users can see all their stored events on the home page within 1 second of page load.
|
||||
- **SC-002**: Users can navigate from the home page to any event detail page in a single tap/click.
|
||||
- **SC-003**: Users can remove an unwanted event from their list in under 3 seconds (including confirmation).
|
||||
- **SC-004**: New users (no stored events) see a clear call-to-action to create their first event.
|
||||
- **SC-005**: Users can distinguish their role (organizer vs. attendee) for each event at a glance without opening the event.
|
||||
|
||||
## Clarifications
|
||||
|
||||
### Session 2026-03-08
|
||||
|
||||
- Q: How does the user trigger event removal? → A: Two mechanisms — visible delete icon on each event card (primary, implemented first) and swipe-to-delete gesture (secondary, implemented separately after).
|
||||
- Q: Placement of "Create Event" button when events exist? → A: Floating Action Button (FAB) fixed at bottom-right corner.
|
||||
- Q: Date/time display format in event list? → A: Relative time labels ("in 3 days", "yesterday") via Intl.RelativeTimeFormat.
|
||||
|
||||
## Assumptions
|
||||
|
||||
- The existing `useEventStorage` composable and `StoredEvent` interface provide all necessary data for the event list (no backend API calls needed for listing).
|
||||
- The event list is purely client-side — there is no server-side "my events" endpoint. Privacy is preserved because events are only known to the user's browser.
|
||||
- The event list uses `Intl.RelativeTimeFormat` for relative time labels (FR-002), while the event detail view uses `Intl.DateTimeFormat` for absolute date/time display. Both use the browser's locale (`navigator.language`).
|
||||
- The "Create Event" flow (spec 006) already saves events to localStorage, so no changes to event creation are needed.
|
||||
- The RSVP flow (spec 008) already saves RSVP data to localStorage, so no changes to RSVP are needed.
|
||||
215
specs/009-list-events/tasks.md
Normal file
215
specs/009-list-events/tasks.md
Normal file
@@ -0,0 +1,215 @@
|
||||
# Tasks: Event List on Home Page
|
||||
|
||||
**Input**: Design documents from `/specs/009-list-events/`
|
||||
**Prerequisites**: plan.md, spec.md, research.md, data-model.md
|
||||
|
||||
**Tests**: Unit tests (Vitest) and E2E tests (Playwright) are included per constitution (Principle II: Test-Driven Methodology).
|
||||
|
||||
**Organization**: Tasks are grouped by user story to enable independent implementation and testing of each story.
|
||||
|
||||
## Format: `[ID] [P?] [Story] Description`
|
||||
|
||||
- **[P]**: Can run in parallel (different files, no dependencies)
|
||||
- **[Story]**: Which user story this task belongs to (e.g., US1, US2, US3)
|
||||
- Include exact file paths in descriptions
|
||||
|
||||
---
|
||||
|
||||
## Phase 1: Setup (Shared Infrastructure)
|
||||
|
||||
**Purpose**: Composable extensions and utility functions shared across all user stories
|
||||
|
||||
- [x] T000 Rename router param `:token` to `:eventToken` in `frontend/src/router/index.ts` and update all references in `EventDetailView.vue`, `EventStubView.vue`, and their test files (consistency with `StoredEvent.eventToken` field name)
|
||||
- [x] T001 Add `isValidStoredEvent` type guard and validation filter to `frontend/src/composables/useEventStorage.ts` (FR-010)
|
||||
- [x] T002 Add `removeEvent(eventToken: string)` function to `frontend/src/composables/useEventStorage.ts` (needed by US3)
|
||||
- [x] T003 [P] Create `useRelativeTime` composable in `frontend/src/composables/useRelativeTime.ts` (Intl.RelativeTimeFormat wrapper, FR-002)
|
||||
- [x] T004 [P] Add unit tests for `isValidStoredEvent` and `removeEvent` in `frontend/src/composables/__tests__/useEventStorage.spec.ts`
|
||||
- [x] T005 [P] Create unit tests for `useRelativeTime` in `frontend/src/composables/__tests__/useRelativeTime.spec.ts`
|
||||
|
||||
**Checkpoint**: Composable layer complete — all shared logic tested and available for components.
|
||||
|
||||
---
|
||||
|
||||
## Phase 2: User Story 1 — View My Events (Priority: P1) 🎯 MVP
|
||||
|
||||
**Goal**: Home page shows all stored events in a sorted list with title and relative time. Tapping navigates to event detail.
|
||||
|
||||
**Independent Test**: Simulate localStorage entries, visit home page, verify all events appear sorted with correct titles and relative times. Tap an event and verify navigation to `/events/:eventToken`.
|
||||
|
||||
### Unit Tests for User Story 1
|
||||
|
||||
- [x] T006 [P] [US1] Create unit tests for EventCard component in `frontend/src/components/__tests__/EventCard.spec.ts` — include test cases for `isPast` prop (faded styling) and role badge rendering (organizer vs. attendee)
|
||||
- [x] T007 [P] [US1] Create unit tests for EventList component in `frontend/src/components/__tests__/EventList.spec.ts`
|
||||
|
||||
### Implementation for User Story 1
|
||||
|
||||
- [x] T008 [P] [US1] Create `EventCard.vue` component in `frontend/src/components/EventCard.vue` — displays title, relative time, role badge; emits click for navigation
|
||||
- [x] T009 [US1] Create `EventList.vue` component in `frontend/src/components/EventList.vue` — reads events from composable, validates, sorts (upcoming asc, past desc), renders EventCard list
|
||||
- [x] T010 [US1] Refactor `HomeView.vue` in `frontend/src/views/HomeView.vue` — integrate EventList, conditionally show list when events exist
|
||||
- [x] T011 [US1] Add event card and list styles to `frontend/src/assets/main.css`
|
||||
|
||||
### E2E Tests for User Story 1
|
||||
|
||||
- [x] T012 [US1] Create E2E test file `frontend/e2e/home-events.spec.ts` — tests: events displayed with title and relative time, sorted correctly, click navigates to detail page
|
||||
|
||||
**Checkpoint**: MVP complete — returning users see their events and can navigate to details.
|
||||
|
||||
---
|
||||
|
||||
## Phase 3: User Story 2 — Empty State (Priority: P2)
|
||||
|
||||
**Goal**: New users with no stored events see an inviting empty state with a "Create Event" call-to-action.
|
||||
|
||||
**Independent Test**: Clear localStorage, visit home page, verify empty state message and "Create Event" button are visible.
|
||||
|
||||
### Unit Tests for User Story 2
|
||||
|
||||
- [x] T013 [P] [US2] Create unit tests for EmptyState component in `frontend/src/components/__tests__/EmptyState.spec.ts`
|
||||
|
||||
### Implementation for User Story 2
|
||||
|
||||
- [x] T014 [US2] Create `EmptyState.vue` component in `frontend/src/components/EmptyState.vue` — shows message and "Create Event" RouterLink
|
||||
- [x] T015 [US2] Update `HomeView.vue` in `frontend/src/views/HomeView.vue` — show EmptyState when no valid events, show EventList otherwise
|
||||
- [x] T016 [US2] Add empty state styles to `frontend/src/assets/main.css`
|
||||
|
||||
### E2E Tests for User Story 2
|
||||
|
||||
- [x] T017 [US2] Add E2E tests to `frontend/e2e/home-events.spec.ts` — tests: empty state shown when no events, hidden when events exist
|
||||
|
||||
**Checkpoint**: Home page handles both new and returning users.
|
||||
|
||||
---
|
||||
|
||||
## Phase 4: User Story 4 — Past Events Appear Faded (Priority: P2)
|
||||
|
||||
**Goal**: Events whose date/time has passed appear with reduced visual prominence (muted colors, lower contrast) while remaining interactive.
|
||||
|
||||
**Independent Test**: Have both future and past events in localStorage, verify past events display faded while remaining clickable.
|
||||
|
||||
### Implementation for User Story 4
|
||||
|
||||
- [x] T018 [US4] Add `.event-card--past` modifier class with `opacity: 0.6; filter: saturate(0.5)` to `frontend/src/components/EventCard.vue` or `frontend/src/assets/main.css`
|
||||
- [x] T019 [US4] Pass `isPast` computed property to EventCard in `EventList.vue` and apply modifier class in `frontend/src/components/EventCard.vue`
|
||||
|
||||
### E2E Tests for User Story 4
|
||||
|
||||
- [x] T020 [US4] Add E2E tests to `frontend/e2e/home-events.spec.ts` — tests: past events have faded class, upcoming events do not, past events remain clickable
|
||||
|
||||
**Checkpoint**: Visual hierarchy distinguishes upcoming from past events.
|
||||
|
||||
---
|
||||
|
||||
## Phase 5: User Story 3 — Remove Event from List (Priority: P3)
|
||||
|
||||
**Goal**: Users can remove events from their local list via delete icon (and later swipe) with confirmation.
|
||||
|
||||
**Independent Test**: Have multiple events, remove one via delete icon, verify it disappears while others remain.
|
||||
|
||||
### Unit Tests for User Story 3
|
||||
|
||||
- [x] T021 [P] [US3] Create unit tests for ConfirmDialog component in `frontend/src/components/__tests__/ConfirmDialog.spec.ts`
|
||||
|
||||
### Implementation for User Story 3
|
||||
|
||||
- [x] T022 [US3] Create `ConfirmDialog.vue` component in `frontend/src/components/ConfirmDialog.vue` — teleport-to-body modal with confirm/cancel, focus trapping, Escape key
|
||||
- [x] T023 [US3] Add delete icon button to `EventCard.vue` in `frontend/src/components/EventCard.vue` — emits `delete` event with eventToken (FR-006a)
|
||||
- [x] T024 [US3] Wire delete flow in `EventList.vue` in `frontend/src/components/EventList.vue` — listen for delete event, show ConfirmDialog, call `removeEvent()` on confirm
|
||||
- [x] T025 [US3] Add delete icon and confirm dialog styles to `frontend/src/assets/main.css`
|
||||
|
||||
### E2E Tests for User Story 3
|
||||
|
||||
- [x] T026 [US3] Add E2E tests to `frontend/e2e/home-events.spec.ts` — tests: delete icon visible, confirmation dialog appears, confirm removes event, cancel keeps event
|
||||
|
||||
**Checkpoint**: Users can manage their event list.
|
||||
|
||||
---
|
||||
|
||||
## Phase 6: User Story 5 — Visual Distinction for Event Roles (Priority: P3)
|
||||
|
||||
**Goal**: Events show a badge indicating whether the user is the organizer or an attendee.
|
||||
|
||||
**Independent Test**: Have events with organizerToken and rsvpToken in localStorage, verify different badges displayed.
|
||||
|
||||
### Implementation for User Story 5
|
||||
|
||||
- [x] T027 [US5] Add role badge (Organizer/Attendee) to `EventCard.vue` in `frontend/src/components/EventCard.vue` — derive from organizerToken/rsvpToken presence
|
||||
- [x] T028 [US5] Add role badge styles to `frontend/src/assets/main.css`
|
||||
|
||||
### E2E Tests for User Story 5
|
||||
|
||||
- [x] T029 [US5] Add E2E tests to `frontend/e2e/home-events.spec.ts` — tests: organizer badge shown for events with organizerToken, attendee badge for events with rsvpToken only
|
||||
|
||||
**Checkpoint**: Role distinction visible at a glance.
|
||||
|
||||
---
|
||||
|
||||
## Phase 7: Polish & Cross-Cutting Concerns
|
||||
|
||||
**Purpose**: FAB, swipe gesture, accessibility, and final polish
|
||||
|
||||
- [x] T030 Create `CreateEventFab.vue` in `frontend/src/components/CreateEventFab.vue` — fixed FAB at bottom-right, navigates to `/create` (FR-011)
|
||||
- [x] T031 Add FAB to `HomeView.vue` in `frontend/src/views/HomeView.vue` — visible when events exist (empty state has its own CTA)
|
||||
- [x] T032 Add FAB styles to `frontend/src/assets/main.css`
|
||||
- [x] T033 Implement swipe-to-delete gesture on EventCard in `frontend/src/components/EventCard.vue` — native Touch API (FR-006b)
|
||||
- [x] T034 Accessibility review: verify ARIA labels, keyboard navigation (Tab/Enter/Escape), focus trapping in ConfirmDialog, WCAG AA contrast on faded cards
|
||||
- [x] T035 Add E2E tests for FAB to `frontend/e2e/home-events.spec.ts` — tests: FAB visible when events exist, navigates to create page
|
||||
|
||||
---
|
||||
|
||||
## Dependencies & Execution Order
|
||||
|
||||
### Phase Dependencies
|
||||
|
||||
- **Phase 1 (Setup)**: No dependencies — start immediately
|
||||
- **Phase 2 (US1)**: Depends on T001, T003 (validation + relative time composable)
|
||||
- **Phase 3 (US2)**: Depends on T001 (validation); can run in parallel with US1
|
||||
- **Phase 4 (US4)**: Depends on Phase 2 completion (EventCard must exist)
|
||||
- **Phase 5 (US3)**: Depends on Phase 2 completion (EventList must exist) + T002 (removeEvent)
|
||||
- **Phase 6 (US5)**: Depends on Phase 2 completion (EventCard must exist)
|
||||
- **Phase 7 (Polish)**: Depends on Phases 2–6 completion
|
||||
|
||||
### User Story Dependencies
|
||||
|
||||
- **US1 (P1)**: Depends only on Phase 1 — no other story dependencies
|
||||
- **US2 (P2)**: Depends only on Phase 1 — independent of US1 but shares HomeView
|
||||
- **US4 (P2)**: Depends on US1 (extends EventCard with past styling)
|
||||
- **US3 (P3)**: Depends on US1 (extends EventList with delete flow)
|
||||
- **US5 (P3)**: Depends on US1 (extends EventCard with role badge)
|
||||
|
||||
### Parallel Opportunities
|
||||
|
||||
- T003 + T004 + T005 can all run in parallel (different files)
|
||||
- T006 + T007 can run in parallel (different test files)
|
||||
- T008 can run in parallel with T006/T007 (component vs test files)
|
||||
- US4, US5 can start in parallel once US1 is done (both extend EventCard independently)
|
||||
|
||||
---
|
||||
|
||||
## Implementation Strategy
|
||||
|
||||
### MVP First (User Story 1 Only)
|
||||
|
||||
1. Complete Phase 1: Setup composables
|
||||
2. Complete Phase 2: US1 — EventCard, EventList, HomeView refactor
|
||||
3. **STOP and VALIDATE**: Test the event list end-to-end
|
||||
4. Deploy/demo if ready
|
||||
|
||||
### Incremental Delivery
|
||||
|
||||
1. Phase 1 → Composable layer ready
|
||||
2. Phase 2 (US1) → Event list works → MVP!
|
||||
3. Phase 3 (US2) → Empty state for new users
|
||||
4. Phase 4 (US4) → Past events faded
|
||||
5. Phase 5 (US3) → Remove events from list
|
||||
6. Phase 6 (US5) → Role badges
|
||||
7. Phase 7 → FAB, swipe, accessibility polish
|
||||
|
||||
---
|
||||
|
||||
## Notes
|
||||
|
||||
- [P] tasks = different files, no dependencies
|
||||
- [Story] label maps task to specific user story for traceability
|
||||
- This is a **frontend-only** feature — no backend changes needed
|
||||
- All data comes from existing `useEventStorage` composable (localStorage)
|
||||
- E2E tests consolidated in single file `home-events.spec.ts` with separate `describe` blocks per story
|
||||
@@ -1,89 +0,0 @@
|
||||
# Feature Specification: Edit Event Details as Organizer
|
||||
|
||||
**Feature**: `010-edit-event`
|
||||
**Created**: 2026-03-06
|
||||
**Status**: Draft
|
||||
**Source**: Migrated from spec/userstories.md
|
||||
|
||||
## User Scenarios & Testing
|
||||
|
||||
### User Story 1 - Edit event details (Priority: P1)
|
||||
|
||||
The event organizer wants to update the details of an event they created — title, description, date/time, location, or expiry date — so that guests always see accurate and up-to-date information if something changes.
|
||||
|
||||
**Why this priority**: Core organizer capability. Edits are expected for any real-world event (date changes, venue updates). Without this, the organizer has no recourse when details change after creation.
|
||||
|
||||
**Independent Test**: Can be fully tested by creating an event (US-1), navigating to the edit form, submitting changed values, and verifying the event page reflects the updates.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** an organizer on the event page with a valid organizer token in localStorage, **When** they navigate to the edit form, **Then** the form is pre-filled with the current event values (title, description, date/time, location, expiry date).
|
||||
2. **Given** the edit form is pre-filled, **When** the organizer modifies one or more fields and submits, **Then** the changes are persisted server-side and the organizer is returned to the event page which reflects the updated details.
|
||||
3. **Given** the organizer is on the event page without an organizer token in localStorage, **When** they attempt to access the edit UI, **Then** no edit option is shown and the server rejects any update request.
|
||||
|
||||
---
|
||||
|
||||
### User Story 2 - Expiry date future-date validation (Priority: P2)
|
||||
|
||||
When editing, the organizer must set the expiry date to a future date. Setting it to today or a past date is rejected, and the organizer is directed to the delete feature (US-19) if they want to remove the event immediately.
|
||||
|
||||
**Why this priority**: Enforces the invariant that an event's expiry date is always in the future. Prevents the expiry date field from being misused as an implicit deletion mechanism, keeping the model clean.
|
||||
|
||||
**Independent Test**: Can be tested by submitting the edit form with a past or current date in the expiry date field and verifying the rejection response and validation message.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** the edit form is open, **When** the organizer sets the expiry date to today or a past date and submits, **Then** the submission is rejected with a clear validation message directing the organizer to use the delete feature (US-19) instead.
|
||||
2. **Given** the edit form is open, **When** the organizer sets the expiry date to a date in the future and submits, **Then** the change is accepted and persisted.
|
||||
|
||||
---
|
||||
|
||||
### User Story 3 - Organizer token authentication (Priority: P2)
|
||||
|
||||
If the organizer token is absent or invalid, neither the edit UI is shown nor the edit request is accepted server-side.
|
||||
|
||||
**Why this priority**: Security constraint — the organizer token is the sole authentication mechanism. Both client and server must enforce it independently.
|
||||
|
||||
**Independent Test**: Can be tested by attempting an edit request with a missing or wrong organizer token and verifying a 403/401 response and no UI exposure.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a visitor without an organizer token in localStorage for the event, **When** they view the event page, **Then** no edit option or link is shown.
|
||||
2. **Given** an edit request is submitted with an absent or invalid organizer token, **When** the server processes the request, **Then** it rejects the request and the event data is unchanged.
|
||||
|
||||
---
|
||||
|
||||
### Edge Cases
|
||||
|
||||
- What happens when the organizer submits the edit form with no changes? The server accepts the submission (idempotent update) and the organizer is returned to the event page.
|
||||
- What happens if the title field is left empty? Submission is rejected with a validation message — title is required.
|
||||
- What happens if the event has expired before the organizer submits the edit form? The server rejects the edit — editing an expired event is not permitted.
|
||||
- How does the system handle concurrent edits (e.g. organizer edits from two devices simultaneously)? [NEEDS EXPANSION — last-write-wins is the simplest strategy]
|
||||
|
||||
## Requirements
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-001**: System MUST allow the organizer to edit: title (required), description (optional), date and time (required), location (optional), expiry date (required).
|
||||
- **FR-002**: System MUST pre-fill the edit form with the current stored values for all editable fields.
|
||||
- **FR-003**: System MUST reject an edit submission where the expiry date is today or in the past, and MUST return a validation message directing the organizer to use the delete feature (US-19).
|
||||
- **FR-004**: System MUST persist all submitted changes server-side upon successful validation.
|
||||
- **FR-005**: System MUST redirect the organizer to the event page after a successful edit, with the updated details visible.
|
||||
- **FR-006**: System MUST NOT expose the edit UI to any visitor who does not have a valid organizer token for the event in localStorage.
|
||||
- **FR-007**: System MUST reject any edit request where the organizer token is absent or does not match the event's stored organizer token.
|
||||
- **FR-008**: No account or additional authentication step beyond the organizer token is required to edit an event.
|
||||
|
||||
### Key Entities
|
||||
|
||||
- **Event**: Mutable entity with fields: title, description, date/time, location, expiry date. Identified externally by its event token. Updated via the organizer token.
|
||||
- **Organizer token**: Secret UUID stored in localStorage on the device where the event was created. Required to authenticate all organizer operations including editing.
|
||||
|
||||
## Success Criteria
|
||||
|
||||
### Measurable Outcomes
|
||||
|
||||
- **SC-001**: An organizer can update any editable field and see the change reflected on the public event page without a page reload after redirect.
|
||||
- **SC-002**: Any attempt to set the expiry date to a non-future date is rejected with a user-visible validation message before the server persists the change.
|
||||
- **SC-003**: No edit operation is possible — client or server — without a valid organizer token.
|
||||
- **SC-004**: The edit form is never shown to a visitor who does not hold the organizer token for the event.
|
||||
- **SC-005**: Visual highlighting of changed fields for guests is deferred to US-9 (Highlight changed event details); this story covers only the server-side persistence and organizer UX of editing.
|
||||
35
specs/010-event-list-grouping/checklists/requirements.md
Normal file
35
specs/010-event-list-grouping/checklists/requirements.md
Normal file
@@ -0,0 +1,35 @@
|
||||
# Specification Quality Checklist: Event List Temporal Grouping
|
||||
|
||||
**Purpose**: Validate specification completeness and quality before proceeding to planning
|
||||
**Created**: 2026-03-08
|
||||
**Feature**: [spec.md](../spec.md)
|
||||
|
||||
## Content Quality
|
||||
|
||||
- [x] No implementation details (languages, frameworks, APIs)
|
||||
- [x] Focused on user value and business needs
|
||||
- [x] Written for non-technical stakeholders
|
||||
- [x] All mandatory sections completed
|
||||
|
||||
## Requirement Completeness
|
||||
|
||||
- [x] No [NEEDS CLARIFICATION] markers remain
|
||||
- [x] Requirements are testable and unambiguous
|
||||
- [x] Success criteria are measurable
|
||||
- [x] Success criteria are technology-agnostic (no implementation details)
|
||||
- [x] All acceptance scenarios are defined
|
||||
- [x] Edge cases are identified
|
||||
- [x] Scope is clearly bounded
|
||||
- [x] Dependencies and assumptions identified
|
||||
|
||||
## Feature Readiness
|
||||
|
||||
- [x] All functional requirements have clear acceptance criteria
|
||||
- [x] User scenarios cover primary flows
|
||||
- [x] Feature meets measurable outcomes defined in Success Criteria
|
||||
- [x] No implementation details leak into specification
|
||||
|
||||
## Notes
|
||||
|
||||
- All items pass. Spec is ready for `/speckit.clarify` or `/speckit.plan`.
|
||||
- One minor note: the Assumptions section mentions `Intl` API and `localStorage` — these are context references to existing behavior, not prescriptive implementation details.
|
||||
91
specs/010-event-list-grouping/data-model.md
Normal file
91
specs/010-event-list-grouping/data-model.md
Normal file
@@ -0,0 +1,91 @@
|
||||
# Data Model: Event List Temporal Grouping
|
||||
|
||||
**Feature**: 010-event-list-grouping | **Date**: 2026-03-08
|
||||
|
||||
## Existing Entities (no changes)
|
||||
|
||||
### StoredEvent
|
||||
|
||||
**Location**: `frontend/src/composables/useEventStorage.ts`
|
||||
|
||||
| Field | Type | Description |
|
||||
|-------|------|-------------|
|
||||
| `eventToken` | `string` | UUID v4, unique identifier |
|
||||
| `organizerToken` | `string?` | UUID v4, present if user is organizer |
|
||||
| `title` | `string` | Event title |
|
||||
| `dateTime` | `string` | ISO 8601 with UTC offset (e.g., `"2026-03-15T20:00:00+01:00"`) |
|
||||
| `expiryDate` | `string` | ISO 8601 expiry date |
|
||||
| `rsvpToken` | `string?` | Present if user has RSVP'd |
|
||||
| `rsvpName` | `string?` | Name used for RSVP |
|
||||
|
||||
**Note**: No changes to `StoredEvent`. The `dateTime` field is the sole input for all grouping and sorting logic.
|
||||
|
||||
## New Types (frontend only)
|
||||
|
||||
### SectionKey
|
||||
|
||||
```typescript
|
||||
type SectionKey = 'today' | 'thisWeek' | 'later' | 'past'
|
||||
```
|
||||
|
||||
Enum-like union type for the four temporal sections. Ordering is fixed: today → thisWeek → later → past.
|
||||
|
||||
### EventSection
|
||||
|
||||
```typescript
|
||||
interface EventSection {
|
||||
key: SectionKey
|
||||
label: string // Display label: "Today", "This Week", "Later", "Past"
|
||||
dateGroups: DateGroup[]
|
||||
emphasized: boolean // true only for 'today' section
|
||||
}
|
||||
```
|
||||
|
||||
Represents one temporal section in the grouped list. Sections with no events are omitted entirely (never constructed).
|
||||
|
||||
### DateGroup
|
||||
|
||||
```typescript
|
||||
interface DateGroup {
|
||||
dateKey: string // YYYY-MM-DD (for keying/dedup)
|
||||
label: string // Formatted via Intl.DateTimeFormat, e.g., "Wed, 12 Mar"
|
||||
events: StoredEvent[] // Events on this date, sorted by time
|
||||
showSubheader: boolean // false for "Today" section (FR-005)
|
||||
}
|
||||
```
|
||||
|
||||
Groups events within a section by their specific calendar date. The `showSubheader` flag controls whether the date subheader is rendered (always false in "Today" section per FR-005).
|
||||
|
||||
## Grouping Algorithm
|
||||
|
||||
```
|
||||
Input: StoredEvent[], now: Date
|
||||
Output: EventSection[]
|
||||
|
||||
1. Compute boundaries:
|
||||
- startOfToday = today at 00:00:00 local
|
||||
- endOfToday = today at 23:59:59.999 local
|
||||
- endOfWeek = next Sunday at 23:59:59.999 local (or today if today is Sunday)
|
||||
|
||||
2. Classify each event by dateTime:
|
||||
- dateTime < startOfToday → "past"
|
||||
- startOfToday ≤ dateTime ≤ endOfToday → "today"
|
||||
- endOfToday < dateTime ≤ endOfWeek → "thisWeek"
|
||||
- dateTime > endOfWeek → "later"
|
||||
|
||||
3. Within each section, group by calendar date (YYYY-MM-DD)
|
||||
|
||||
4. Sort:
|
||||
- today/thisWeek/later: date groups ascending, events within group ascending by time
|
||||
- past: date groups descending, events within group descending by time
|
||||
|
||||
5. Emit only non-empty sections in fixed order: today, thisWeek, later, past
|
||||
```
|
||||
|
||||
## State Transitions
|
||||
|
||||
None. Events are static data in localStorage. Temporal classification is computed on each render based on current time. No event mutation occurs.
|
||||
|
||||
## Validation Rules
|
||||
|
||||
No new validation. Existing `isValidStoredEvent()` in `useEventStorage.ts` already validates the `dateTime` field as a parseable ISO 8601 string.
|
||||
72
specs/010-event-list-grouping/plan.md
Normal file
72
specs/010-event-list-grouping/plan.md
Normal file
@@ -0,0 +1,72 @@
|
||||
# Implementation Plan: Event List Temporal Grouping
|
||||
|
||||
**Branch**: `010-event-list-grouping` | **Date**: 2026-03-08 | **Spec**: `specs/010-event-list-grouping/spec.md`
|
||||
**Input**: Feature specification from `/specs/010-event-list-grouping/spec.md`
|
||||
|
||||
## Summary
|
||||
|
||||
Extend the existing flat event list with temporal section grouping (Today, This Week, Later, Past). The feature is purely client-side: the existing `EventList.vue` computed property that separates events into upcoming/past is refactored into a four-section grouping with section headers, date subheaders, and context-aware time formatting. No backend changes, no new dependencies.
|
||||
|
||||
## Technical Context
|
||||
|
||||
**Language/Version**: TypeScript 5.9 (frontend only)
|
||||
**Primary Dependencies**: Vue 3, Vue Router 5 (existing — no additions)
|
||||
**Storage**: localStorage via `useEventStorage.ts` composable (existing — no changes)
|
||||
**Testing**: Vitest (unit), Playwright + MSW (E2E)
|
||||
**Target Platform**: PWA, mobile-first, all modern browsers
|
||||
**Project Type**: Web application (frontend enhancement)
|
||||
**Performance Goals**: Grouping computation < 1ms for 100 events (trivial — single array pass)
|
||||
**Constraints**: Client-side only, no additional network requests, offline-capable
|
||||
**Scale/Scope**: Typically < 50 events per user in localStorage
|
||||
|
||||
## Constitution Check
|
||||
|
||||
*GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.*
|
||||
|
||||
| Principle | Status | Notes |
|
||||
|-----------|--------|-------|
|
||||
| I. Privacy by Design | PASS | No new data collection. Grouping uses existing `dateTime` field. No external services. |
|
||||
| II. Test-Driven Methodology | PASS | Unit tests for grouping logic + E2E tests for all user stories planned. TDD enforced. |
|
||||
| III. API-First Development | N/A | No API changes — purely frontend enhancement. |
|
||||
| IV. Simplicity & Quality | PASS | Minimal new code: one composable for grouping, template changes in EventList. No over-engineering. |
|
||||
| V. Dependency Discipline | PASS | No new dependencies. Uses browser `Intl` API and existing `Date` methods. |
|
||||
| VI. Accessibility | PASS | Section headers use semantic HTML (`<h2>`/`<h3>`), ARIA landmarks, keyboard navigable. WCAG AA contrast enforced. |
|
||||
|
||||
**Gate result: PASS** — no violations.
|
||||
|
||||
## Project Structure
|
||||
|
||||
### Documentation (this feature)
|
||||
|
||||
```text
|
||||
specs/010-event-list-grouping/
|
||||
├── plan.md # This file
|
||||
├── research.md # Phase 0 output
|
||||
├── data-model.md # Phase 1 output
|
||||
├── spec.md # Feature specification
|
||||
└── tasks.md # Phase 2 output (via /speckit.tasks)
|
||||
```
|
||||
|
||||
### Source Code (repository root)
|
||||
|
||||
```text
|
||||
frontend/
|
||||
├── src/
|
||||
│ ├── components/
|
||||
│ │ ├── EventList.vue # MODIFY — add section grouping to template + computed
|
||||
│ │ ├── EventCard.vue # MODIFY — add time format mode prop
|
||||
│ │ ├── SectionHeader.vue # NEW — temporal section header component
|
||||
│ │ └── DateSubheader.vue # NEW — date subheader component
|
||||
│ ├── composables/
|
||||
│ │ ├── useEventGrouping.ts # NEW — grouping logic (pure function)
|
||||
│ │ ├── useRelativeTime.ts # EXISTING — no changes
|
||||
│ │ └── useEventStorage.ts # EXISTING — no changes
|
||||
│ └── components/__tests__/
|
||||
│ ├── EventList.spec.ts # MODIFY — update for grouped structure
|
||||
│ ├── EventCard.spec.ts # MODIFY — add time format tests
|
||||
│ └── useEventGrouping.spec.ts # NEW — unit tests for grouping logic
|
||||
├── e2e/
|
||||
│ └── home-events.spec.ts # MODIFY — add temporal grouping E2E tests
|
||||
```
|
||||
|
||||
**Structure Decision**: Frontend-only changes. Two new small components (SectionHeader, DateSubheader) and one new composable (useEventGrouping). Existing components modified minimally.
|
||||
118
specs/010-event-list-grouping/research.md
Normal file
118
specs/010-event-list-grouping/research.md
Normal file
@@ -0,0 +1,118 @@
|
||||
# Research: Event List Temporal Grouping
|
||||
|
||||
**Feature**: 010-event-list-grouping | **Date**: 2026-03-08
|
||||
|
||||
## 1. Week Boundary Calculation
|
||||
|
||||
**Decision**: Use ISO 8601 week convention (Monday = first day of week). "This Week" spans from tomorrow through Sunday of the current week.
|
||||
|
||||
**Rationale**: The spec explicitly states "ISO convention where Monday is the first day of the week" (Assumptions section). The browser's `Date.getDay()` returns 0 for Sunday, 1 for Monday — straightforward to compute end-of-week as next Sunday 23:59:59.
|
||||
|
||||
**Implementation**: Compare event date against:
|
||||
- `startOfToday` and `endOfToday` for "Today"
|
||||
- `startOfTomorrow` and `endOfSunday` for "This Week"
|
||||
- `after endOfSunday` for "Later"
|
||||
- `before startOfToday` for "Past"
|
||||
|
||||
Edge case (spec scenario 4): On Sunday, "This Week" is empty (tomorrow is already next week Monday), so events for Monday appear under "Later". This falls out naturally from the algorithm.
|
||||
|
||||
**Alternatives considered**:
|
||||
- Using a date library (date-fns, luxon): Rejected — dependency discipline (Constitution V). Native `Date` + `Intl` is sufficient for this logic.
|
||||
- Locale-dependent week start: Rejected — spec mandates ISO convention explicitly.
|
||||
|
||||
## 2. Date Formatting for Subheaders
|
||||
|
||||
**Decision**: Use `Intl.DateTimeFormat` with `{ weekday: 'short', day: 'numeric', month: 'short' }` to produce labels like "Wed, 12 Mar".
|
||||
|
||||
**Rationale**: Consistent with existing use of `Intl.RelativeTimeFormat` in `useRelativeTime.ts`. Respects user locale for month/weekday names. No external dependency needed.
|
||||
|
||||
**Alternatives considered**:
|
||||
- Hardcoded English day/month names: Rejected — the project already uses `Intl` APIs for locale awareness.
|
||||
- Full date format (e.g., "Wednesday, March 12, 2026"): Rejected — too long for mobile cards.
|
||||
|
||||
## 3. Time Display on Event Cards
|
||||
|
||||
**Decision**: Add a `timeDisplayMode` prop to `EventCard.vue` with two modes:
|
||||
- `'clock'`: Shows formatted time (e.g., "18:30") using `Intl.DateTimeFormat` with `{ hour: '2-digit', minute: '2-digit' }`
|
||||
- `'relative'`: Shows relative time (e.g., "3 days ago") using existing `formatRelativeTime()`
|
||||
|
||||
**Rationale**: Spec requires different time representations per section: clock time for Today/This Week/Later, relative time for Past. A prop-driven approach keeps EventCard stateless regarding section context.
|
||||
|
||||
**Alternatives considered**:
|
||||
- EventCard determining its own display mode: Rejected — card shouldn't know about sections; parent owns that context.
|
||||
- Passing a pre-formatted string: Viable but less type-safe. A mode enum is clearer.
|
||||
|
||||
## 4. Grouping Data Structure
|
||||
|
||||
**Decision**: The `useEventGrouping` composable returns an array of section objects:
|
||||
|
||||
```typescript
|
||||
interface EventSection {
|
||||
key: 'today' | 'thisWeek' | 'later' | 'past'
|
||||
label: string // "Today", "This Week", "Later", "Past"
|
||||
events: GroupedEvent[]
|
||||
}
|
||||
|
||||
interface DateGroup {
|
||||
date: string // ISO date string (YYYY-MM-DD) for keying
|
||||
label: string // Formatted date label (e.g., "Wed, 12 Mar")
|
||||
events: StoredEvent[]
|
||||
}
|
||||
|
||||
interface GroupedEvent extends StoredEvent {
|
||||
dateGroup: string // ISO date for sub-grouping
|
||||
}
|
||||
```
|
||||
|
||||
Actually, simpler: the composable returns sections, each containing date groups, each containing events.
|
||||
|
||||
```typescript
|
||||
interface EventSection {
|
||||
key: 'today' | 'thisWeek' | 'later' | 'past'
|
||||
label: string
|
||||
dateGroups: DateGroup[]
|
||||
}
|
||||
|
||||
interface DateGroup {
|
||||
dateKey: string // YYYY-MM-DD
|
||||
label: string // Formatted: "Wed, 12 Mar"
|
||||
events: StoredEvent[]
|
||||
}
|
||||
```
|
||||
|
||||
**Rationale**: Two-level grouping (section → date → events) matches the spec's hierarchy. Empty sections are simply omitted from the returned array (FR-002). The "Today" section still has one DateGroup but the template skips rendering its subheader (FR-005).
|
||||
|
||||
**Alternatives considered**:
|
||||
- Flat list with section markers: Harder to template, mixes data and presentation.
|
||||
- Map/Record structure: Arrays preserve ordering guarantees (Today → This Week → Later → Past).
|
||||
|
||||
## 5. Visual Emphasis for "Today" Section
|
||||
|
||||
**Decision**: Apply a CSS class `.section--today` to the Today section that uses:
|
||||
- Slightly larger section header (font-weight: 800, font-size: 1.1rem vs 700/1rem for others)
|
||||
- A subtle left border accent using the primary gradient pink (`#F06292`)
|
||||
|
||||
**Rationale**: Consistent with Electric Dusk design system. Subtle enough not to distract but visually distinct. The existing past-event fade (opacity: 0.6, saturate: 0.5) already handles the other end of the spectrum.
|
||||
|
||||
**Alternatives considered**:
|
||||
- Background highlight: Could clash with card backgrounds on mobile.
|
||||
- Icon/emoji prefix: Spec doesn't mention icons; keep it typography-driven per design system.
|
||||
|
||||
## 6. Accessibility Considerations
|
||||
|
||||
**Decision**:
|
||||
- Section headers are `<h2>` elements
|
||||
- Date subheaders are `<h3>` elements
|
||||
- The event list container keeps its existing `role="list"`
|
||||
- Each section is a `<section>` element with `aria-label` matching the section label
|
||||
|
||||
**Rationale**: Constitution VI requires semantic HTML and ARIA. The heading hierarchy (h2 > h3) provides screen reader navigation landmarks. The `<section>` element with label allows assistive technology to announce section boundaries.
|
||||
|
||||
## 7. Existing Test Updates
|
||||
|
||||
**Decision**:
|
||||
- Existing `EventList.spec.ts` unit tests will be updated to account for the new grouped structure (sections instead of flat list)
|
||||
- Existing `home-events.spec.ts` E2E tests will be extended with new scenarios for temporal grouping
|
||||
- New `useEventGrouping.spec.ts` tests the pure grouping function in isolation
|
||||
|
||||
**Rationale**: TDD (Constitution II). The grouping logic is a pure function — ideal for thorough unit testing with various date combinations and edge cases.
|
||||
138
specs/010-event-list-grouping/spec.md
Normal file
138
specs/010-event-list-grouping/spec.md
Normal file
@@ -0,0 +1,138 @@
|
||||
# Feature Specification: Event List Temporal Grouping
|
||||
|
||||
**Feature Branch**: `010-event-list-grouping`
|
||||
**Created**: 2026-03-08
|
||||
**Status**: Draft
|
||||
**Input**: User description: "Extend the event list with temporal grouping so users know if an event is today, this week, or further in the future."
|
||||
|
||||
## User Scenarios & Testing *(mandatory)*
|
||||
|
||||
### User Story 1 - Temporal Section Headers (Priority: P1)
|
||||
|
||||
As a user viewing my event list, I want events grouped under clear date-based section headers so I can instantly see what's happening today, this week, and later without reading individual dates.
|
||||
|
||||
The list displays events under these temporal sections (in order):
|
||||
|
||||
1. **Today** — events happening today
|
||||
2. **This Week** — events from tomorrow through end of current week (Sunday)
|
||||
3. **Later** — upcoming events beyond this week
|
||||
4. **Past** — events that have already occurred
|
||||
|
||||
Each section only appears if it contains at least one event. Empty sections are hidden entirely.
|
||||
|
||||
**Why this priority**: The core value of this feature — temporal orientation at a glance. Without section headers, the rest of the feature has no foundation.
|
||||
|
||||
**Independent Test**: Can be fully tested by adding events with various dates to localStorage and verifying they appear under the correct section headers.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a user has events today, tomorrow, next week, and last week, **When** they view the event list, **Then** they see four sections: "Today", "This Week", "Later", and "Past" with events correctly distributed.
|
||||
2. **Given** a user has only events for today, **When** they view the event list, **Then** only the "Today" section is visible — no empty sections appear.
|
||||
3. **Given** a user has no events at all, **When** they view the event list, **Then** the empty state is shown (as currently implemented).
|
||||
4. **Given** it is Sunday and an event is scheduled for Monday, **When** the user views the list, **Then** the Monday event appears under "Later" (not "This Week"), because the current week ends on Sunday.
|
||||
|
||||
---
|
||||
|
||||
### User Story 2 - Date Subheaders Within Sections (Priority: P2)
|
||||
|
||||
Within each section (except "Today"), events are further grouped by their specific date with a subheader showing the formatted date (e.g., "Sat, 17 Sep"). This mirrors the inspiration layout where individual dates appear as smaller headings under the main temporal section.
|
||||
|
||||
Within the "Today" section, no date subheader is needed since all events share the same date.
|
||||
|
||||
**Why this priority**: Adds finer-grained orientation within sections — especially important when "This Week" or "Later" contain multiple events across different days.
|
||||
|
||||
**Independent Test**: Can be tested by adding multiple events on different days within the same temporal section and verifying date subheaders appear.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a user has events on Wednesday and Friday of this week, **When** they view the "This Week" section, **Then** events are grouped under date subheaders like "Wed, 12 Mar" and "Fri, 14 Mar".
|
||||
2. **Given** a user has three events today, **When** they view the "Today" section, **Then** no date subheader appears — events are listed directly under the "Today" header.
|
||||
3. **Given** two events on the same future date, **When** the user views the list, **Then** both appear under a single date subheader for that day, sorted by time.
|
||||
|
||||
---
|
||||
|
||||
### User Story 3 - Enhanced Event Card Information (Priority: P2)
|
||||
|
||||
Each event card within the grouped list shows time information relevant to its context:
|
||||
|
||||
- **Today's events**: Show the time (e.g., "18:30") prominently, since the date is implied by the section.
|
||||
- **Future events**: Show the time (e.g., "18:30") — the date is provided by the subheader.
|
||||
- **Past events**: Continue showing relative time (e.g., "3 days ago") as currently implemented, since exact time matters less.
|
||||
|
||||
The existing role badges (Organizer/Attendee) and event title remain as-is.
|
||||
|
||||
**Why this priority**: Completes the information design — users need different time representations depending on temporal context.
|
||||
|
||||
**Independent Test**: Can be tested by checking that event cards display the correct time format based on which section they appear in.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** an event today at 18:30, **When** the user views the "Today" section, **Then** the card shows "18:30" (not "in 3 hours").
|
||||
2. **Given** an event on Friday at 10:00, **When** the user views it under "This Week", **Then** the card shows "10:00".
|
||||
3. **Given** a past event from 3 days ago, **When** the user views the "Past" section, **Then** the card shows "3 days ago" as it does currently.
|
||||
|
||||
---
|
||||
|
||||
### User Story 4 - Today Section Visual Emphasis (Priority: P3)
|
||||
|
||||
The "Today" section header and its event cards receive subtle visual emphasis to draw the user's attention to what's happening now. This could be a slightly larger section header, bolder typography, or a subtle highlight — consistent with the Electric Dusk design system.
|
||||
|
||||
Past events continue to appear visually faded (reduced opacity/saturation) as currently implemented.
|
||||
|
||||
**Why this priority**: Nice visual polish that reinforces the temporal hierarchy, but the feature works without it.
|
||||
|
||||
**Independent Test**: Can be verified visually by checking that the "Today" section stands out compared to other sections.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** events exist for today and later, **When** the user views the list, **Then** the "Today" section is visually more prominent than other sections.
|
||||
2. **Given** only past events exist, **When** the user views the list, **Then** the "Past" section uses the existing faded treatment without any special emphasis.
|
||||
|
||||
---
|
||||
|
||||
### Edge Cases
|
||||
|
||||
- What happens when the user's device clock is set incorrectly? Events may appear in the wrong section — this is acceptable, no special handling needed.
|
||||
- What happens at midnight when "today" changes? The grouping updates on next page load or navigation; real-time re-sorting is not required.
|
||||
- What happens with an event at exactly midnight (00:00)? It belongs to the day it falls on — same as any other time.
|
||||
- What happens when a section has many events (10+)? All events are shown; no pagination or truncation within sections.
|
||||
|
||||
## Requirements *(mandatory)*
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-001**: System MUST group events into temporal sections: "Today", "This Week", "Later", and "Past".
|
||||
- **FR-002**: System MUST hide sections that contain no events.
|
||||
- **FR-003**: System MUST display section headers with the temporal label (e.g., "Today", "This Week").
|
||||
- **FR-004**: System MUST display date subheaders within "This Week", "Later", and "Past" sections when events span multiple days.
|
||||
- **FR-005**: System MUST NOT display a date subheader within the "Today" section.
|
||||
- **FR-006**: System MUST sort events within each section by time ascending (earliest first) for upcoming events and by time descending (most recent first) for past events.
|
||||
- **FR-007**: System MUST display clock time (e.g., "18:30") on event cards in "Today", "This Week", and "Later" sections.
|
||||
- **FR-008**: System MUST display relative time (e.g., "3 days ago") on event cards in the "Past" section.
|
||||
- **FR-009**: System MUST visually emphasize the "Today" section compared to other sections.
|
||||
- **FR-010**: System MUST continue to fade past events visually (as currently implemented).
|
||||
- **FR-011**: System MUST preserve existing functionality: role badges, swipe-to-delete, delete confirmation, empty state.
|
||||
- **FR-012**: "This Week" MUST include events from tomorrow through the end of the current calendar week (Sunday).
|
||||
|
||||
### Key Entities
|
||||
|
||||
- **Temporal Section**: A grouping label ("Today", "This Week", "Later", "Past") that organizes events by their relationship to the current date.
|
||||
- **Date Subheader**: A formatted date label (e.g., "Sat, 17 Sep") that groups events within a temporal section by their specific date.
|
||||
- **StoredEvent**: Existing entity — no changes to its structure are required. The `dateTime` field is used for all grouping and sorting logic.
|
||||
|
||||
## Success Criteria *(mandatory)*
|
||||
|
||||
### Measurable Outcomes
|
||||
|
||||
- **SC-001**: Users can identify how many events they have today within 2 seconds of viewing the list.
|
||||
- **SC-002**: Every event in the list is assigned to exactly one temporal section — no event appears in multiple sections or is missing.
|
||||
- **SC-003**: Section ordering is always consistent: Today > This Week > Later > Past.
|
||||
- **SC-004**: The feature works entirely client-side with no additional network requests beyond what currently exists.
|
||||
- **SC-005**: All existing event list functionality (delete, navigation, role badges) continues to work unchanged.
|
||||
|
||||
## Assumptions
|
||||
|
||||
- The user's locale and timezone are used for determining "today" and formatting dates/times (via the browser's `Intl` API, consistent with existing approach).
|
||||
- "Week" follows ISO convention where Monday is the first day of the week. "This Week" runs from tomorrow through Sunday.
|
||||
- The design system (Electric Dusk + Sora) applies to all new visual elements. The inspiration screenshot's color theme is explicitly NOT adopted.
|
||||
- No backend changes are needed — this is a purely frontend enhancement to the existing client-side event list.
|
||||
189
specs/010-event-list-grouping/tasks.md
Normal file
189
specs/010-event-list-grouping/tasks.md
Normal file
@@ -0,0 +1,189 @@
|
||||
# Tasks: Event List Temporal Grouping
|
||||
|
||||
**Input**: Design documents from `/specs/010-event-list-grouping/`
|
||||
**Prerequisites**: plan.md, spec.md, research.md, data-model.md
|
||||
|
||||
**Tests**: Included — spec.md references TDD (Constitution II), and research.md explicitly plans unit + E2E test updates.
|
||||
|
||||
**Organization**: Tasks are grouped by user story to enable independent implementation and testing of each story.
|
||||
|
||||
## Format: `[ID] [P?] [Story] Description`
|
||||
|
||||
- **[P]**: Can run in parallel (different files, no dependencies)
|
||||
- **[Story]**: Which user story this task belongs to (e.g., US1, US2, US3)
|
||||
- Include exact file paths in descriptions
|
||||
|
||||
---
|
||||
|
||||
## Phase 1: Setup
|
||||
|
||||
**Purpose**: No new project setup needed — this is a frontend-only enhancement to an existing codebase. Phase 1 is empty.
|
||||
|
||||
*(No tasks — existing project structure is sufficient.)*
|
||||
|
||||
---
|
||||
|
||||
## Phase 2: Foundational (Blocking Prerequisites)
|
||||
|
||||
**Purpose**: Create the core grouping composable and its types — all user stories depend on this logic.
|
||||
|
||||
**CRITICAL**: No user story work can begin until this phase is complete.
|
||||
|
||||
- [ ] T001 Define `SectionKey`, `EventSection`, and `DateGroup` types in `frontend/src/composables/useEventGrouping.ts`
|
||||
- [ ] T002 Implement `useEventGrouping` composable with section classification, date grouping, and sorting logic in `frontend/src/composables/useEventGrouping.ts`
|
||||
- [ ] T003 Write unit tests for `useEventGrouping` covering all four sections, empty-section omission, sort order, and Sunday edge case in `frontend/src/components/__tests__/useEventGrouping.spec.ts`
|
||||
|
||||
**Checkpoint**: Grouping logic is fully tested and ready for consumption by UI components.
|
||||
|
||||
---
|
||||
|
||||
## Phase 3: User Story 1 — Temporal Section Headers (Priority: P1) MVP
|
||||
|
||||
**Goal**: Events appear grouped under "Today", "This Week", "Later", and "Past" section headers. Empty sections are hidden.
|
||||
|
||||
**Independent Test**: Add events with various dates to localStorage, verify they appear under correct section headers.
|
||||
|
||||
### Tests for User Story 1
|
||||
|
||||
> **NOTE: Write these tests FIRST, ensure they FAIL before implementation**
|
||||
|
||||
- [ ] T004 [P] [US1] Write unit tests for `SectionHeader.vue` rendering section label and emphasis flag in `frontend/src/components/__tests__/SectionHeader.spec.ts`
|
||||
- [ ] T005 [P] [US1] Update `EventList.spec.ts` tests to expect grouped section structure instead of flat list in `frontend/src/components/__tests__/EventList.spec.ts`
|
||||
|
||||
### Implementation for User Story 1
|
||||
|
||||
- [ ] T006 [P] [US1] Create `SectionHeader.vue` component with section label (`<h2>`) and `aria-label` in `frontend/src/components/SectionHeader.vue`
|
||||
- [ ] T007 [US1] Refactor `EventList.vue` template to use `useEventGrouping`, render `<section>` per temporal group with `SectionHeader`, and hide empty sections in `frontend/src/components/EventList.vue`
|
||||
- [ ] T008 [US1] Update E2E tests in `home-events.spec.ts` to verify section headers appear with correct events distributed across "Today", "This Week", "Later", "Past" in `frontend/e2e/home-events.spec.ts`
|
||||
|
||||
**Checkpoint**: Event list shows temporal section headers. All four acceptance scenarios pass.
|
||||
|
||||
---
|
||||
|
||||
## Phase 4: User Story 2 — Date Subheaders Within Sections (Priority: P2)
|
||||
|
||||
**Goal**: Within each section (except "Today"), events are further grouped by date with formatted subheaders like "Wed, 12 Mar".
|
||||
|
||||
**Independent Test**: Add multiple events on different days within one section, verify date subheaders appear.
|
||||
|
||||
### Tests for User Story 2
|
||||
|
||||
> **NOTE: Write these tests FIRST, ensure they FAIL before implementation**
|
||||
|
||||
- [ ] T009 [P] [US2] Write unit tests for `DateSubheader.vue` rendering formatted date label in `frontend/src/components/__tests__/DateSubheader.spec.ts`
|
||||
- [ ] T010 [P] [US2] Add unit tests to `EventList.spec.ts` verifying date subheaders appear within sections and are absent in "Today" in `frontend/src/components/__tests__/EventList.spec.ts`
|
||||
|
||||
### Implementation for User Story 2
|
||||
|
||||
- [ ] T011 [P] [US2] Create `DateSubheader.vue` component with formatted date (`<h3>`) using `Intl.DateTimeFormat` in `frontend/src/components/DateSubheader.vue`
|
||||
- [ ] T012 [US2] Update `EventList.vue` template to render `DateSubheader` within each section's date groups, skipping subheader for "Today" section (`showSubheader` flag) in `frontend/src/components/EventList.vue`
|
||||
- [ ] T013 [US2] Add E2E test scenarios for date subheaders: multiple days within a section, no subheader in "Today" in `frontend/e2e/home-events.spec.ts`
|
||||
|
||||
**Checkpoint**: Date subheaders render correctly within sections. "Today" section has no subheader.
|
||||
|
||||
---
|
||||
|
||||
## Phase 5: User Story 3 — Enhanced Event Card Time Display (Priority: P2)
|
||||
|
||||
**Goal**: Event cards show clock time ("18:30") in Today/This Week/Later sections and relative time ("3 days ago") in Past section.
|
||||
|
||||
**Independent Test**: Check event cards display the correct time format based on which section they appear in.
|
||||
|
||||
### Tests for User Story 3
|
||||
|
||||
> **NOTE: Write these tests FIRST, ensure they FAIL before implementation**
|
||||
|
||||
- [ ] T014 [P] [US3] Add unit tests to `EventCard.spec.ts` for `timeDisplayMode` prop: `'clock'` renders formatted time, `'relative'` renders relative time in `frontend/src/components/__tests__/EventCard.spec.ts`
|
||||
|
||||
### Implementation for User Story 3
|
||||
|
||||
- [ ] T015 [US3] Add `timeDisplayMode` prop (`'clock' | 'relative'`) to `EventCard.vue`, render clock time via `Intl.DateTimeFormat({ hour: '2-digit', minute: '2-digit' })` or existing `formatRelativeTime()` in `frontend/src/components/EventCard.vue`
|
||||
- [ ] T016 [US3] Update `EventList.vue` to pass `timeDisplayMode="clock"` for today/thisWeek/later sections and `timeDisplayMode="relative"` for past section in `frontend/src/components/EventList.vue`
|
||||
- [ ] T017 [US3] Add E2E test scenarios verifying clock time in future sections and relative time in past section in `frontend/e2e/home-events.spec.ts`
|
||||
|
||||
**Checkpoint**: Time display adapts to section context. All three acceptance scenarios pass.
|
||||
|
||||
---
|
||||
|
||||
## Phase 6: User Story 4 — Today Section Visual Emphasis (Priority: P3)
|
||||
|
||||
**Goal**: The "Today" section header is visually more prominent (bolder, slightly larger, accent border) than other sections.
|
||||
|
||||
**Independent Test**: Visual verification that "Today" stands out compared to other section headers.
|
||||
|
||||
- [ ] T018 [US4] Add `.section--today` CSS class to `SectionHeader.vue` with `font-weight: 800`, `font-size: 1.1rem`, and left border accent (`#F06292`) — triggered by `emphasized` prop in `frontend/src/components/SectionHeader.vue`
|
||||
- [ ] T019 [US4] Verify `EventList.vue` passes `emphasized: true` for the "Today" section (already set via `EventSection.emphasized` from data model) in `frontend/src/components/EventList.vue`
|
||||
- [ ] T020 [US4] Add visual E2E assertion checking that the "Today" section header has the emphasis CSS class applied in `frontend/e2e/home-events.spec.ts`
|
||||
|
||||
**Checkpoint**: "Today" section is visually distinct. Past events remain faded.
|
||||
|
||||
---
|
||||
|
||||
## Phase 7: Polish & Cross-Cutting Concerns
|
||||
|
||||
**Purpose**: Final validation and regression checks.
|
||||
|
||||
- [ ] T021 Run full unit test suite (`cd frontend && npm run test:unit`) and fix any regressions
|
||||
- [ ] T022 Run full E2E test suite and verify all existing functionality (swipe-to-delete, role badges, empty state, navigation) still works in `frontend/e2e/home-events.spec.ts`
|
||||
- [ ] T023 Verify accessibility: section headers are `<h2>`, date subheaders are `<h3>`, sections have `aria-label`, keyboard navigation works
|
||||
|
||||
---
|
||||
|
||||
## Dependencies & Execution Order
|
||||
|
||||
### Phase Dependencies
|
||||
|
||||
- **Setup (Phase 1)**: Empty — no work needed
|
||||
- **Foundational (Phase 2)**: No dependencies — can start immediately
|
||||
- **US1 (Phase 3)**: Depends on Phase 2 (grouping composable)
|
||||
- **US2 (Phase 4)**: Depends on Phase 3 (needs section structure in EventList)
|
||||
- **US3 (Phase 5)**: Depends on Phase 3 (needs section context for time mode)
|
||||
- **US4 (Phase 6)**: Depends on Phase 3 (needs SectionHeader component)
|
||||
- **Polish (Phase 7)**: Depends on all user stories being complete
|
||||
|
||||
### User Story Dependencies
|
||||
|
||||
- **US1 (P1)**: Can start after Foundational — no dependencies on other stories
|
||||
- **US2 (P2)**: Depends on US1 (needs section structure in template to add subheaders)
|
||||
- **US3 (P2)**: Depends on US1 (needs section context to determine time mode), independent of US2
|
||||
- **US4 (P3)**: Depends on US1 (needs SectionHeader component), independent of US2/US3
|
||||
|
||||
### Parallel Opportunities
|
||||
|
||||
- **Phase 2**: T001 must precede T002; T003 can run after T002
|
||||
- **Phase 3**: T004 and T005 in parallel; T006 in parallel with tests; T007 after T006
|
||||
- **Phase 4**: T009 and T010 in parallel; T011 in parallel with tests; T012 after T011
|
||||
- **Phase 5**: T014 can start as soon as US1 is done; T015 after T014; T016 after T015
|
||||
- **Phase 6**: T018 can run in parallel with Phase 5 (different files)
|
||||
- **US3 and US4** can run in parallel after US1 completes
|
||||
|
||||
---
|
||||
|
||||
## Parallel Example: After US1 Completes
|
||||
|
||||
```bash
|
||||
# These can run in parallel (different files, no dependencies):
|
||||
Task: T009 [US2] Write DateSubheader unit tests
|
||||
Task: T014 [US3] Write EventCard time mode unit tests
|
||||
Task: T018 [US4] Add .section--today CSS to SectionHeader.vue
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Implementation Strategy
|
||||
|
||||
### MVP First (User Story 1 Only)
|
||||
|
||||
1. Complete Phase 2: Foundational (grouping composable + tests)
|
||||
2. Complete Phase 3: User Story 1 (section headers in EventList)
|
||||
3. **STOP and VALIDATE**: Test US1 independently
|
||||
4. Deploy/demo if ready — list is already grouped with headers
|
||||
|
||||
### Incremental Delivery
|
||||
|
||||
1. Phase 2 → Grouping logic ready
|
||||
2. Add US1 → Section headers visible → Deploy/Demo (MVP!)
|
||||
3. Add US2 → Date subheaders within sections → Deploy/Demo
|
||||
4. Add US3 → Context-aware time display → Deploy/Demo
|
||||
5. Add US4 → Visual polish for "Today" → Deploy/Demo
|
||||
6. Each story adds value without breaking previous stories
|
||||
@@ -1,90 +0,0 @@
|
||||
# Feature Specification: Bookmark an Event
|
||||
|
||||
**Feature**: `011-bookmark-event`
|
||||
**Created**: 2026-03-06
|
||||
**Status**: Draft
|
||||
**Source**: Migrated from spec/userstories.md
|
||||
|
||||
> **Note on directory naming**: The migration task list labeled this directory `us-06-calendar-export`, but US-6 in userstories.md is "Bookmark an event". Calendar export is US-8. The directory was created with the correct name reflecting the actual story content.
|
||||
|
||||
## User Scenarios & Testing
|
||||
|
||||
### User Story 1 - Bookmark an event without RSVP (Priority: P1)
|
||||
|
||||
A guest who has opened an event page wants to save it for later without committing to attendance. They activate a "Remember" / "Follow" action on the event page. The event token, title, and date are stored in localStorage — no server request is made. The bookmark persists across browser sessions on the same device. The guest can unfollow by activating the action again.
|
||||
|
||||
**Why this priority**: Core bookmarking capability — without this, the entire feature has no value.
|
||||
|
||||
**Independent Test**: Can be fully tested by visiting an event page, activating the bookmark action, closing the browser, and reopening to verify persistence. Delivers value by enabling the local event overview (US-7) to display bookmarked events.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a guest has opened an event page, **When** they activate the "Remember" / "Follow" action, **Then** the event token, title, and date are stored in localStorage and no server request is made.
|
||||
2. **Given** a guest has bookmarked an event, **When** they close and reopen the browser, **Then** the bookmark is still present in localStorage.
|
||||
3. **Given** a guest has bookmarked an event, **When** they activate the bookmark action again, **Then** the bookmark is removed from localStorage ("unfollow") without any server contact.
|
||||
4. **Given** a guest has bookmarked an event, **When** the event page is loaded again, **Then** the bookmark action reflects the current bookmarked state.
|
||||
|
||||
---
|
||||
|
||||
### User Story 2 - Bookmark is independent of RSVP state (Priority: P2)
|
||||
|
||||
A guest who has already RSVPed to an event on their device can still explicitly bookmark or un-bookmark the event. The bookmark state is tracked separately from RSVP state.
|
||||
|
||||
**Why this priority**: Important for correctness but not the primary use case. The primary scenario is the undecided guest who wants to remember without committing.
|
||||
|
||||
**Independent Test**: Can be tested by RSVPing to an event and then toggling the bookmark action — both states persist independently in localStorage.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a guest has RSVPed "attending" on this device, **When** they activate the bookmark action, **Then** the bookmark is stored independently and the RSVP state is unaffected.
|
||||
2. **Given** a guest has bookmarked an event and RSVPed, **When** they remove the bookmark, **Then** the RSVP state is unaffected.
|
||||
|
||||
---
|
||||
|
||||
### User Story 3 - Bookmark available on expired events (Priority: P2)
|
||||
|
||||
A guest who is viewing an event that has passed its expiry date can still bookmark it, so it remains visible in their local event overview (US-7).
|
||||
|
||||
**Why this priority**: Edge case that ensures continuity of the local overview even for past events.
|
||||
|
||||
**Independent Test**: Can be tested by visiting an expired event page and verifying the bookmark action is present and functional.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** an event has passed its expiry date, **When** a guest views the event page, **Then** the bookmark action is still shown and functional.
|
||||
2. **Given** a guest bookmarks an expired event, **When** they view their local event overview (US-7), **Then** the event appears in the list marked as ended.
|
||||
|
||||
---
|
||||
|
||||
### Edge Cases
|
||||
|
||||
- What happens when the event title or date changes after bookmarking? Locally cached title and date may become stale if the organizer edits the event — this is an accepted trade-off. Cached values are refreshed when the guest next visits the event page.
|
||||
- How does the app handle localStorage being unavailable (e.g. private browsing in some browsers)? [NEEDS EXPANSION]
|
||||
- What happens if the guest bookmarks the same event from multiple devices? Each device maintains its own independent bookmark — no server-side sync.
|
||||
|
||||
## Requirements
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-001**: The event page MUST display a "Remember" / "Follow" action accessible to any visitor holding the event link.
|
||||
- **FR-002**: Activating the bookmark action MUST store the event token, event title, and event date in localStorage with no server request.
|
||||
- **FR-003**: The bookmark MUST persist across browser sessions on the same device.
|
||||
- **FR-004**: A second activation of the bookmark action MUST remove the bookmark ("unfollow") with no server contact.
|
||||
- **FR-005**: The bookmark state MUST be independent of the RSVP state — both can coexist for the same event on the same device.
|
||||
- **FR-006**: The bookmark action MUST remain available on event pages where the event has expired.
|
||||
- **FR-007**: No personal data, IP address, or identifier MUST be transmitted to the server when bookmarking or un-bookmarking.
|
||||
- **FR-008**: The bookmark action MUST reflect the current state (bookmarked / not bookmarked) when the event page loads.
|
||||
|
||||
### Key Entities
|
||||
|
||||
- **Bookmark record** (localStorage): Stored per event token. Contains: event token, event title, event date. Indicates the guest has explicitly bookmarked this event without RSVPing. Independent of the RSVP record.
|
||||
|
||||
## Success Criteria
|
||||
|
||||
### Measurable Outcomes
|
||||
|
||||
- **SC-001**: A guest can bookmark an event and find it in their local overview (US-7) without any server contact at any point in the bookmark flow.
|
||||
- **SC-002**: Bookmarking and un-bookmarking produce no network requests (verifiable via browser DevTools).
|
||||
- **SC-003**: A bookmark persists after browser restart on the same device.
|
||||
- **SC-004**: The bookmark state is correctly reflected on the event page across multiple sessions.
|
||||
- **SC-005**: Guests with existing RSVPs on this device can independently toggle the bookmark without affecting their RSVP state.
|
||||
@@ -1,111 +0,0 @@
|
||||
# Feature Specification: Local Event Overview List
|
||||
|
||||
**Feature**: `012-local-event-overview`
|
||||
**Created**: 2026-03-06
|
||||
**Status**: Draft
|
||||
**Source**: Migrated from spec/userstories.md
|
||||
|
||||
## User Scenarios & Testing
|
||||
|
||||
### User Story 1 - View tracked events on the root page (Priority: P1)
|
||||
|
||||
A user who has created, bookmarked, or RSVPed to events on this device opens the root page (`/`) and sees a list of all those events, each with the event title, date, and their relationship to the event (organizer / attending / not attending / bookmarked only). Each entry is a link to the event page. The list is rendered entirely from localStorage — no server request is required. If no events are tracked locally, an empty state is shown.
|
||||
|
||||
**Why this priority**: This is the core feature — the reason the overview exists. Without this story, no other scenario is meaningful.
|
||||
|
||||
**Independent Test**: Can be fully tested by seeding localStorage with event entries (simulating US-1/US-3/US-6 data) and loading the root page. Delivers value by allowing users to navigate back to any tracked event without the original link.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** the user has created an event from this device (organizer token in localStorage), **When** they navigate to `/`, **Then** the event appears in the list with title, date, and relationship "organizer"
|
||||
2. **Given** the user has RSVPed "attending" to an event from this device, **When** they navigate to `/`, **Then** the event appears in the list with title, date, and relationship "attending"
|
||||
3. **Given** the user has RSVPed "not attending" to an event from this device, **When** they navigate to `/`, **Then** the event appears in the list with title, date, and relationship "not attending"
|
||||
4. **Given** the user has bookmarked an event from this device (US-6), **When** they navigate to `/`, **Then** the event appears in the list with title, date, and relationship "bookmarked only"
|
||||
5. **Given** no events are tracked in localStorage, **When** the user navigates to `/`, **Then** an empty state message is shown — not an error
|
||||
6. **Given** the list is rendered, **When** the user clicks an entry, **Then** they are navigated directly to the event page for that entry
|
||||
|
||||
---
|
||||
|
||||
### User Story 2 - Visually distinguish past events (Priority: P2)
|
||||
|
||||
Events whose date has passed are still shown in the list but rendered with a visual distinction (e.g. marked as "ended"), so the user can differentiate between upcoming and past events at a glance.
|
||||
|
||||
**Why this priority**: Useful for UX clarity but the overview is still functional without this distinction. Past events in the list are still navigable.
|
||||
|
||||
**Independent Test**: Can be tested by placing a past-dated event entry in localStorage and loading the root page. The entry should appear visually distinct from current events.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** an event in localStorage has a date in the past, **When** the user views the overview, **Then** the entry is visually distinguished (e.g. marked "ended") compared to upcoming events
|
||||
2. **Given** an event in localStorage has a date in the future, **When** the user views the overview, **Then** the entry is rendered without any "ended" indicator
|
||||
|
||||
---
|
||||
|
||||
### User Story 3 - Remove an entry from the local list (Priority: P2)
|
||||
|
||||
The user can remove individual entries from the local overview. The behavior depends on the entry type: for bookmarked-only events the bookmark is removed; for RSVPed events the local record is removed (server-side RSVP unaffected); for organizer-created events the organizer token and event data are removed from localStorage, with a confirmation warning that organizer access on this device will be lost.
|
||||
|
||||
**Why this priority**: Important for list hygiene but not required for the core navigation use case.
|
||||
|
||||
**Independent Test**: Can be tested by placing entries of each type in localStorage and verifying removal behavior from the overview UI.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a bookmarked-only event is in the local list, **When** the user removes that entry, **Then** the bookmark is removed from localStorage and the entry disappears from the list
|
||||
2. **Given** an RSVPed event is in the local list, **When** the user removes that entry, **Then** the local RSVP record is removed from localStorage; the server-side RSVP is unaffected
|
||||
3. **Given** an organizer-created event is in the local list, **When** the user initiates removal, **Then** a confirmation warning is shown explaining that organizer access on this device will be revoked
|
||||
4. **Given** the organizer confirms removal, **Then** the organizer token and event metadata are removed from localStorage and the entry disappears from the list
|
||||
|
||||
---
|
||||
|
||||
### User Story 4 - Handle a deleted event when navigating from the overview (Priority: P2)
|
||||
|
||||
If the user clicks an entry in the local overview and the server responds that the event no longer exists (deleted per US-12 automatic cleanup or US-19 organizer deletion), the app displays an "event no longer exists" message and offers to remove the entry from the local list.
|
||||
|
||||
**Why this priority**: Edge case that improves consistency and prevents stale entries from accumulating, but not core to the overview's primary purpose.
|
||||
|
||||
**Independent Test**: Can be tested by navigating to an event whose token does not exist on the server. The app should display a "no longer exists" message and offer removal.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** an entry exists in the local overview, **When** the user navigates to that event and the server returns "event not found", **Then** the app displays an "event no longer exists" message and offers to remove the entry from the local list
|
||||
2. **Given** the user confirms removal of the stale entry, **Then** the entry is removed from localStorage and the user is returned to the overview
|
||||
|
||||
---
|
||||
|
||||
### Edge Cases
|
||||
|
||||
- What happens if localStorage is unavailable or disabled in the browser? The overview cannot render — [NEEDS EXPANSION: define fallback message or behavior]
|
||||
- What happens if the same event appears under multiple localStorage keys (e.g. both RSVPed and organizer)? [NEEDS EXPANSION: define de-duplication or priority rule for relationship label]
|
||||
- What happens if an event's locally cached title or date is stale (organizer edited via US-5)? Stale values are displayed until the user next visits the event page — this is an accepted trade-off per the story notes.
|
||||
- What happens when the user has a very large number of tracked events? [NEEDS EXPANSION: pagination or truncation strategy]
|
||||
|
||||
## Requirements
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-001**: The root page (`/`) MUST display the local event overview list below a project header/branding section
|
||||
- **FR-002**: The list MUST include any event for which an organizer token, RSVP record, or bookmark exists in localStorage for this device
|
||||
- **FR-003**: Each list entry MUST show at minimum: event title, event date, and the user's relationship to the event (organizer / attending / not attending / bookmarked only)
|
||||
- **FR-004**: Each list entry MUST be a link that navigates directly to the corresponding event page
|
||||
- **FR-005**: The list MUST be populated entirely from localStorage — no server request is made to render the overview
|
||||
- **FR-006**: Events whose date has passed MUST be visually distinguished (e.g. marked "ended") from upcoming events
|
||||
- **FR-007**: An individual entry MUST be removable from the list; removal behavior depends on entry type (bookmark removal, local RSVP record removal, or organizer token removal)
|
||||
- **FR-008**: Removing an organizer-created event entry MUST require a confirmation warning explaining that organizer access on this device will be revoked
|
||||
- **FR-009**: No personal data or event data MUST be transmitted to the server when viewing or interacting with the overview
|
||||
- **FR-010**: If no events are tracked locally, an empty state MUST be shown — not an error or blank screen
|
||||
- **FR-011**: When navigating from the overview to an event that the server reports as deleted, the app MUST display an "event no longer exists" message and offer to remove the stale entry from the local list
|
||||
|
||||
### Key Entities
|
||||
|
||||
- **LocalEventEntry**: A localStorage-stored record representing one tracked event. Contains at minimum: event token, event title, event date, and relationship type (organizer / attending / not attending / bookmarked). May also contain: organizer token (for organizer entries), RSVP choice and name (for RSVP entries).
|
||||
|
||||
## Success Criteria
|
||||
|
||||
### Measurable Outcomes
|
||||
|
||||
- **SC-001**: A user with events tracked in localStorage can navigate to `/` and see all tracked events without any server request being made
|
||||
- **SC-002**: Each event entry links correctly to its event page
|
||||
- **SC-003**: Past events are visually distinguishable from upcoming events in the list
|
||||
- **SC-004**: An entry can be removed from the list, and the corresponding localStorage key is cleaned up correctly for each entry type
|
||||
- **SC-005**: The empty state is shown when no events are tracked in localStorage — no blank page or error state
|
||||
@@ -1,92 +0,0 @@
|
||||
# Feature Specification: Add Event to Calendar
|
||||
|
||||
**Feature**: `013-calendar-export`
|
||||
**Created**: 2026-03-06
|
||||
**Status**: Draft
|
||||
**Source**: Migrated from spec/userstories.md
|
||||
|
||||
## User Scenarios & Testing
|
||||
|
||||
### User Story 1 - Download .ics file (Priority: P1)
|
||||
|
||||
A guest who wants to remember the event opens the event page and downloads an iCalendar file to import into their personal calendar application. The file contains all relevant event details: title, description, start date/time, location, and the public event URL. The UID in the file is derived from the event token so that re-downloading the file and re-importing it updates the existing calendar entry rather than creating a duplicate.
|
||||
|
||||
**Why this priority**: Core calendar integration — the most common and universally supported way to add an event to a calendar across all platforms.
|
||||
|
||||
**Independent Test**: Can be fully tested by visiting a valid event page, clicking the `.ics` download link, and verifying the downloaded file is a valid iCalendar (RFC 5545) document with the correct event fields and a stable UID.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a valid event page, **When** the guest clicks the `.ics` download link, **Then** a standards-compliant iCalendar file is downloaded containing the event title, description (if present), start date and time, location (if present), the public event URL, and a unique UID derived from the event token.
|
||||
2. **Given** the guest downloads the `.ics` file twice for the same event, **When** they import both files into a calendar application, **Then** the calendar application updates the existing entry rather than creating a duplicate (due to the stable UID).
|
||||
3. **Given** a guest holding only the event link (no RSVP, no login), **When** they access the `.ics` download link, **Then** the file is served without requiring any authentication or personal data.
|
||||
4. **Given** an event whose expiry date has passed, **When** the guest accesses the `.ics` download link, **Then** the file is still served (the guest can still obtain the calendar record of a past event).
|
||||
|
||||
---
|
||||
|
||||
### User Story 2 - Subscribe via webcal:// link (Priority: P2)
|
||||
|
||||
A guest subscribes to the event via a `webcal://` link so that their calendar application automatically picks up any changes — such as a rescheduled date or updated location — when the organizer edits the event via US-5.
|
||||
|
||||
**Why this priority**: Adds live-update value on top of the static `.ics` download. Requires the `.ics` download (P1) to already work. Most useful in conjunction with US-5 (Edit event details).
|
||||
|
||||
**Independent Test**: Can be tested by opening the `webcal://` URL in a calendar application and verifying it subscribes to the feed and shows the correct event details.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a valid event page, **When** the guest clicks the `webcal://` subscription link, **Then** their calendar application subscribes to the feed and displays the event.
|
||||
2. **Given** a subscribed `webcal://` feed and an organizer who edits the event date via US-5, **When** the calendar application syncs the feed, **Then** the calendar entry is updated to reflect the new date.
|
||||
3. **Given** a `webcal://` endpoint, **When** it is accessed, **Then** it serves identical iCalendar content as the `.ics` download, using the same event token in the URL.
|
||||
|
||||
---
|
||||
|
||||
### User Story 3 - Cancelled event reflected in calendar (Priority: P3)
|
||||
|
||||
When an event is cancelled (US-18), the `.ics` file and `webcal://` feed include `STATUS:CANCELLED` so that subscribed calendar applications reflect the cancellation automatically on their next sync.
|
||||
|
||||
**Why this priority**: Quality-of-life enhancement dependent on US-18 (cancel event). Deferred until US-18 is implemented.
|
||||
|
||||
**Independent Test**: Can be tested by cancelling an event and verifying the calendar feed includes `STATUS:CANCELLED`.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** an event that has been cancelled (US-18), **When** a calendar application syncs the `webcal://` feed, **Then** the calendar entry is updated to show the cancelled status.
|
||||
2. **Given** an event that has been cancelled (US-18), **When** the guest downloads the `.ics` file, **Then** it includes `STATUS:CANCELLED`.
|
||||
|
||||
> **Note**: Deferred until US-18 is implemented.
|
||||
|
||||
---
|
||||
|
||||
### Edge Cases
|
||||
|
||||
- What happens when the event has no description or location? The `.ics` file must omit those optional fields rather than including blank values.
|
||||
- What happens if the server has no public URL configured? The event URL included in the `.ics` file must always be the correct public event URL.
|
||||
- What happens if the event's date or timezone changes after a guest already imported the `.ics` file? The static import will be stale; the `webcal://` subscription will auto-update on next sync.
|
||||
|
||||
## Requirements
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-001**: System MUST expose a server-side endpoint that generates and serves a standards-compliant iCalendar (RFC 5545) `.ics` file for any event identified by its event token.
|
||||
- **FR-002**: The `.ics` file MUST include: event title, description (if present), start date and time, location (if present), the public event URL, and a unique UID derived from the event token.
|
||||
- **FR-003**: The UID in the `.ics` file MUST be stable across regenerations (same event token always produces the same UID) so that calendar applications update existing entries on re-import rather than creating duplicates.
|
||||
- **FR-004**: The `.ics` file MUST be generated server-side; no external calendar or QR code service is called.
|
||||
- **FR-005**: System MUST expose a `webcal://` subscription endpoint that serves identical iCalendar content as the `.ics` download, using the same event token in the URL.
|
||||
- **FR-006**: Both the `.ics` download link and the `webcal://` subscription link MUST be accessible to any visitor holding the event link — no RSVP, login, or personal data required.
|
||||
- **FR-007**: No personal data, name, or IP address MUST be logged when either link is accessed.
|
||||
- **FR-008**: Both links MUST remain available and functional after the event's expiry date has passed.
|
||||
- **FR-009**: When an event is cancelled (US-18), the `.ics` file and `webcal://` feed MUST include `STATUS:CANCELLED`. [Deferred until US-18 is implemented]
|
||||
|
||||
### Key Entities
|
||||
|
||||
- **CalendarFeed**: A virtual resource derived from the Event entity. Identified by the event token. Serialized to iCalendar (RFC 5545) format on demand. Has no independent storage — always generated from current event state.
|
||||
|
||||
## Success Criteria
|
||||
|
||||
### Measurable Outcomes
|
||||
|
||||
- **SC-001**: Downloading the `.ics` file and importing it into a standard calendar application (Google Calendar, Apple Calendar, Outlook) results in the event appearing with correct title, date/time, and location.
|
||||
- **SC-002**: Re-importing the `.ics` file after an event edit updates the existing calendar entry rather than creating a duplicate.
|
||||
- **SC-003**: Subscribing via `webcal://` and triggering a calendar sync after an event edit (US-5) reflects the updated details in the calendar application.
|
||||
- **SC-004**: Both endpoints are accessible without authentication and without transmitting any personal data.
|
||||
- **SC-005**: No external service is contacted during `.ics` generation or `webcal://` feed serving.
|
||||
@@ -1,107 +0,0 @@
|
||||
# Feature Specification: Highlight Changed Event Details
|
||||
|
||||
**Feature**: `014-highlight-changes`
|
||||
**Created**: 2026-03-06
|
||||
**Status**: Draft
|
||||
**Source**: Migrated from spec/userstories.md
|
||||
|
||||
> **NOTE on directory name**: The migration task list specified `us-09-reminders` for this directory, but US-9 in userstories.md is "Highlight changed event details". The directory has been created as `014-highlight-changes` to match the actual story content. This is consistent with corrections made in iterations 16 (us-06-bookmark-event) and 18 (us-08-calendar-export).
|
||||
|
||||
## User Scenarios & Testing
|
||||
|
||||
### User Story 1 - Guest sees highlight for recently changed fields (Priority: P1)
|
||||
|
||||
A guest opens an event page that the organizer has edited since the guest's last visit. Changed fields (e.g. new date, new location) are visually highlighted so the guest immediately notices what is different. After the page loads, the highlight is cleared for the next visit.
|
||||
|
||||
**Why this priority**: Core value of the feature — guests must notice important updates like a rescheduled date or changed location without having to read the entire page again.
|
||||
|
||||
**Independent Test**: Can be fully tested by creating an event, visiting it (establishing `last_seen_at`), editing it as organizer, then revisiting as guest — changed fields appear highlighted; unmodified fields do not.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a guest has previously visited an event page (establishing `last_seen_at` in localStorage), **When** the organizer saves an edit that changes one or more fields, **Then** on the guest's next visit those changed fields are visually highlighted with a "recently changed" indicator.
|
||||
2. **Given** an event with an edit, **When** a guest opens the event page and the `last_edited_at` timestamp is newer than the stored `last_seen_at`, **Then** only the fields changed in the most recent edit are highlighted; unmodified fields are not highlighted.
|
||||
3. **Given** a guest who has seen the latest edit, **When** they visit the event page again without any new edits having occurred, **Then** no highlights are shown.
|
||||
|
||||
---
|
||||
|
||||
### User Story 2 - No highlight on first visit (Priority: P2)
|
||||
|
||||
A guest opens an event page for the first time (no `last_seen_at` in localStorage). Even if the organizer has made edits since creation, no "recently changed" highlights are shown — the event is new to the guest, so labelling fields as changed would be misleading.
|
||||
|
||||
**Why this priority**: Correctness requirement. Showing highlights on first visit would be confusing because the guest has no reference point for what "changed" means.
|
||||
|
||||
**Independent Test**: Can be tested by clearing localStorage and opening an edited event page — no highlight indicators should appear.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** no `last_seen_at` value in localStorage for a given event token, **When** a guest opens the event page, **Then** no field highlights are shown regardless of whether the organizer has made edits.
|
||||
2. **Given** a first visit with no `last_seen_at`, **When** the event page is rendered, **Then** `last_seen_at` is written to localStorage with the current `last_edited_at` value, so the next visit will correctly compare against it.
|
||||
|
||||
---
|
||||
|
||||
### User Story 3 - Highlight clears after viewing (Priority: P2)
|
||||
|
||||
After the guest views the highlighted changes, the highlight is cleared on the next visit. Subsequent visits to the same event page (without new edits) show no highlights.
|
||||
|
||||
**Why this priority**: Without this, the highlight would become permanent noise rather than a meaningful "new change" signal.
|
||||
|
||||
**Independent Test**: Can be tested by visiting an event page with a change (seeing highlights), then visiting again — highlights should be gone.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a guest views an event page with highlighted fields, **When** the page is rendered, **Then** `last_seen_at` in localStorage is updated to match the current `last_edited_at`.
|
||||
2. **Given** `last_seen_at` was updated on the previous visit, **When** the guest visits the event page again (with no new edits), **Then** no highlights are shown.
|
||||
|
||||
---
|
||||
|
||||
### User Story 4 - Only most recent edit is tracked (Priority: P3)
|
||||
|
||||
If the organizer makes multiple successive edits, only the fields changed in the most recent edit are highlighted. Intermediate changes between visits are not accumulated.
|
||||
|
||||
**Why this priority**: Simplicity constraint — tracking the full change history is overengineered for this scope. Guests see what changed last, not everything that ever changed.
|
||||
|
||||
**Independent Test**: Can be tested by making two successive edits to different fields, then visiting as a guest — only fields from the second edit are highlighted.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** an organizer edits the event twice (first changing title, then changing location), **When** a guest visits the page after both edits, **Then** only the location is highlighted (changed in the most recent edit); title is not highlighted (changed in an earlier edit).
|
||||
2. **Given** an event with no edits since creation, **When** any guest visits the event page, **Then** no highlights are shown.
|
||||
|
||||
---
|
||||
|
||||
### Edge Cases
|
||||
|
||||
- What if the organizer edits the event while the guest has the page open? The highlight logic runs on page load; open-page state is stale and will be corrected on the next visit.
|
||||
- What if localStorage is unavailable (e.g. private browsing)? No `last_seen_at` can be stored, so the guest is treated as a first-time visitor and no highlights are shown. This is safe and graceful.
|
||||
- What if `last_edited_at` is null (event has never been edited)? No highlights are shown. The field-change metadata is only populated on the first actual edit.
|
||||
|
||||
## Requirements
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-001**: System MUST record which fields changed (title, description, date/time, location) and store a `last_edited_at` timestamp server-side whenever the organizer saves an edit (US-5).
|
||||
- **FR-002**: System MUST include `last_edited_at` and the set of changed field names in the event page API response.
|
||||
- **FR-003**: Client MUST store a `last_seen_at` value per event token in localStorage, set to the event's `last_edited_at` on each page render.
|
||||
- **FR-004**: Client MUST compare the event's `last_edited_at` against the stored `last_seen_at` on page load to determine whether highlights should be shown.
|
||||
- **FR-005**: Client MUST display a "recently changed" visual indicator next to each field that appears in the server's changed-fields set, only when `last_edited_at` is newer than `last_seen_at`.
|
||||
- **FR-006**: Client MUST NOT show any highlights when no `last_seen_at` is present in localStorage for the event (first visit).
|
||||
- **FR-007**: Client MUST NOT show any highlights when `last_edited_at` is null or equal to `last_seen_at`.
|
||||
- **FR-008**: Client MUST update `last_seen_at` in localStorage after rendering the event page, regardless of whether highlights were shown.
|
||||
- **FR-009**: System MUST NOT transmit any visit data or `last_seen_at` value to the server — the read-state tracking is entirely client-side.
|
||||
- **FR-010**: System MUST track only the most recent edit's changed fields; intermediate changes between visits are not accumulated.
|
||||
|
||||
### Key Entities
|
||||
|
||||
- **EditMetadata** (server-side): Records `last_edited_at` timestamp and the set of changed field names for an event. Associated with the event record. Populated on first edit; overwritten on each subsequent edit.
|
||||
- **last_seen_at** (client-side, localStorage): Per-event-token timestamp. Records when the guest last viewed the event page. Used to determine whether highlights should be shown. Never transmitted to the server.
|
||||
|
||||
## Success Criteria
|
||||
|
||||
### Measurable Outcomes
|
||||
|
||||
- **SC-001**: A guest who has visited an event page before an edit correctly sees highlight indicators on the changed fields when revisiting after the edit.
|
||||
- **SC-002**: A guest who visits an event page for the first time sees no highlight indicators, even if edits have been made.
|
||||
- **SC-003**: Highlights disappear on the guest's next visit after they have viewed the highlighted changes.
|
||||
- **SC-004**: No server request beyond the normal event page load is required to determine whether highlights should be shown.
|
||||
- **SC-005**: No visit data or read-state information is transmitted to the server — privacy is fully preserved.
|
||||
@@ -1,74 +0,0 @@
|
||||
# Feature Specification: Post Update Messages as Organizer
|
||||
|
||||
**Feature**: `015-organizer-updates`
|
||||
**Created**: 2026-03-06
|
||||
**Status**: Draft
|
||||
**Source**: Migrated from spec/userstories.md
|
||||
|
||||
## User Scenarios & Testing
|
||||
|
||||
### User Story 1 - Post and manage update messages (Priority: P1)
|
||||
|
||||
As an event organizer, I want to post short update messages on the event page and manage them, so that guests are informed of announcements or notes without requiring a separate communication channel.
|
||||
|
||||
**Why this priority**: The ability to post and display update messages is the core capability of this feature. Without it, nothing else in this story is testable.
|
||||
|
||||
**Independent Test**: Can be tested by creating an event, posting an update message via the organizer view, and verifying the message appears on the public event page.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a valid organizer token is present in localStorage, **When** the organizer submits a plain-text update message, **Then** the message is stored server-side with a timestamp and appears on the public event page in reverse chronological order.
|
||||
2. **Given** multiple update messages have been posted, **When** a guest opens the event page, **Then** all messages are displayed newest-first, each with a human-readable timestamp.
|
||||
3. **Given** a valid organizer token is present in localStorage, **When** the organizer deletes a previously posted update message, **Then** the message is permanently removed and no longer appears on the public event page.
|
||||
4. **Given** no organizer token is present in localStorage, **When** a visitor views the event page, **Then** no compose or delete UI is shown and the server rejects any attempt to post or delete update messages.
|
||||
|
||||
---
|
||||
|
||||
### User Story 2 - Block posting after event expiry (Priority: P2)
|
||||
|
||||
As an event organizer, I want to be prevented from posting update messages after the event's expiry date has passed, so that the system remains consistent with the event lifecycle.
|
||||
|
||||
**Why this priority**: Expiry enforcement is a consistency constraint on top of the core posting capability.
|
||||
|
||||
**Independent Test**: Can be tested by attempting to post an update message via the API after an event's expiry date and verifying a rejection response is returned.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** an event has passed its expiry date, **When** the organizer attempts to submit an update message, **Then** the server rejects the request and the message is not stored.
|
||||
|
||||
---
|
||||
|
||||
### Edge Cases
|
||||
|
||||
- What happens if the organizer submits an empty or whitespace-only update message?
|
||||
- What is the maximum length of an update message? [NEEDS EXPANSION]
|
||||
- How many update messages can an event accumulate? [NEEDS EXPANSION]
|
||||
- Cancelled events (US-18): posting update messages is not blocked by cancellation, only by expiry — the organizer may want to post post-cancellation communication (e.g. a rescheduling notice or explanation).
|
||||
|
||||
## Requirements
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-001**: System MUST allow the organizer to compose and submit a plain-text update message from the organizer view when a valid organizer token is present in localStorage.
|
||||
- **FR-002**: System MUST store each submitted update message server-side, associated with the event, with a server-assigned timestamp at the time of posting.
|
||||
- **FR-003**: System MUST display all update messages for an event on the public event page in reverse chronological order (newest first), each with a human-readable timestamp.
|
||||
- **FR-004**: System MUST reject any attempt to post an update message after the event's expiry date has passed.
|
||||
- **FR-005**: System MUST allow the organizer to permanently delete any previously posted update message from the organizer view.
|
||||
- **FR-006**: System MUST immediately remove a deleted update message from the public event page upon deletion.
|
||||
- **FR-007**: System MUST reject any attempt to post or delete update messages when the organizer token is absent or invalid.
|
||||
- **FR-008**: System MUST NOT show the compose or delete UI to visitors who do not have a valid organizer token in localStorage.
|
||||
- **FR-009**: System MUST NOT log personal data or IP addresses when update messages are fetched or posted.
|
||||
|
||||
### Key Entities
|
||||
|
||||
- **UpdateMessage**: A plain-text message associated with an event. Key attributes: event reference, message body (plain text), created_at timestamp. Owned by the event; deleted when the event is deleted (US-12, US-19) or manually removed by the organizer.
|
||||
|
||||
## Success Criteria
|
||||
|
||||
### Measurable Outcomes
|
||||
|
||||
- **SC-001**: A posted update message appears on the public event page without requiring a page reload beyond the normal navigation.
|
||||
- **SC-002**: Deleting an update message removes it from the public event page immediately upon deletion confirmation.
|
||||
- **SC-003**: An attempt to post an update message without a valid organizer token returns a 4xx error response from the server.
|
||||
- **SC-004**: An attempt to post an update message after the event's expiry date returns a 4xx error response from the server.
|
||||
- **SC-005**: No IP addresses or personal data appear in server logs when update messages are fetched or posted.
|
||||
@@ -1,84 +0,0 @@
|
||||
# Feature Specification: New-Update Indicator for Guests
|
||||
|
||||
**Feature**: `016-guest-notifications`
|
||||
**Created**: 2026-03-06
|
||||
**Status**: Draft
|
||||
**Source**: Migrated from spec/userstories.md
|
||||
|
||||
## User Scenarios & Testing
|
||||
|
||||
### User Story 1 - Unread update indicator (Priority: P1)
|
||||
|
||||
A guest opens the event page and sees a visual indicator (badge or highlighted section) drawing attention to update messages that were posted since their last visit. The read state is tracked entirely in localStorage — no server involvement.
|
||||
|
||||
**Why this priority**: Core purpose of this feature. Without this, guests miss new organizer announcements unless they manually read through all messages.
|
||||
|
||||
**Independent Test**: Can be tested by opening an event page after new update messages have been posted, verifying that a badge or visual highlight appears on the update messages section.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a guest has previously visited the event page and `updates_last_seen_at` is stored in localStorage, **When** they return and the event has updates newer than `updates_last_seen_at`, **Then** a visual indicator is shown drawing attention to the unread messages.
|
||||
2. **Given** the event page is rendered with unread updates shown, **When** the page finishes loading, **Then** `updates_last_seen_at` in localStorage is updated to the timestamp of the most recent update, so the indicator does not appear on the next visit.
|
||||
3. **Given** a guest opens the event page and all updates are older than the stored `updates_last_seen_at`, **When** the page loads, **Then** no "new update" indicator is shown.
|
||||
|
||||
---
|
||||
|
||||
### User Story 2 - First visit: no indicator (Priority: P2)
|
||||
|
||||
A guest who has never visited the event page before (no `updates_last_seen_at` in localStorage) sees the update messages without any "new" badge or indicator.
|
||||
|
||||
**Why this priority**: A first-time visitor has not established a baseline; labeling existing updates as "new" would be misleading since they have never seen the event before.
|
||||
|
||||
**Independent Test**: Can be tested by opening an event page on a device with no prior localStorage state for that event token, verifying that no unread indicator is shown even if update messages are present.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a guest opens an event page for the first time (no `updates_last_seen_at` in localStorage for this event token), **When** the page loads and update messages are present, **Then** no "new update" indicator is shown and `updates_last_seen_at` is initialized to the most recent update timestamp.
|
||||
|
||||
---
|
||||
|
||||
### User Story 3 - No server read-tracking (Priority: P1)
|
||||
|
||||
No server request is made to record that a guest viewed the updates. The read state is purely client-side.
|
||||
|
||||
**Why this priority**: Fundamental privacy requirement — tracking which guests have read which updates would be a form of user surveillance, violating the project's privacy statutes.
|
||||
|
||||
**Independent Test**: Can be tested by inspecting network traffic when a guest opens the event page, verifying that no "mark as read" or analytics request is sent.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a guest opens the event page with unread updates, **When** the page loads and `updates_last_seen_at` is updated in localStorage, **Then** no additional server request is made to record the read event.
|
||||
|
||||
---
|
||||
|
||||
### Edge Cases
|
||||
|
||||
- What happens when all update messages are deleted (US-10a) and a guest reopens the page? The stored `updates_last_seen_at` should remain in localStorage; no indicator is shown since there are no updates to compare against.
|
||||
- What happens if localStorage is unavailable (private browsing, storage quota exceeded)? The indicator is not shown (degrades gracefully); no error is displayed to the user.
|
||||
- The `updates_last_seen_at` key is separate from the `last_seen_at` key used in US-9 (field-change highlights). The two mechanisms operate independently.
|
||||
|
||||
## Requirements
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-001**: System MUST display a visual indicator (badge or highlighted section) on the event page when the guest has unread update messages, determined by comparing the newest update's timestamp against `updates_last_seen_at` stored in localStorage.
|
||||
- **FR-002**: System MUST store the `updates_last_seen_at` timestamp in localStorage per event token after each page render, so the indicator clears on subsequent visits.
|
||||
- **FR-003**: System MUST NOT show a "new update" indicator on a guest's first visit to an event page (when no `updates_last_seen_at` exists in localStorage for that event token).
|
||||
- **FR-004**: System MUST initialize `updates_last_seen_at` in localStorage on first visit, set to the timestamp of the most recent update (or a sentinel value if no updates exist), to prevent spurious indicators on subsequent visits.
|
||||
- **FR-005**: System MUST NOT transmit any data to the server when a guest views or is marked as having read update messages — read tracking is purely client-side.
|
||||
- **FR-006**: System MUST use a localStorage key distinct from the `last_seen_at` key used in US-9 to avoid conflicts between the two read-state mechanisms.
|
||||
- **FR-007**: System MUST degrade gracefully if localStorage is unavailable: no indicator is shown, and no error is surfaced to the user.
|
||||
|
||||
### Key Entities
|
||||
|
||||
- **UpdateReadState** (client-side only): Stored in localStorage, keyed by event token. Contains `updates_last_seen_at` (timestamp of the most recent update at last visit). Never transmitted to the server.
|
||||
|
||||
## Success Criteria
|
||||
|
||||
### Measurable Outcomes
|
||||
|
||||
- **SC-001**: A guest who has not visited an event page since a new update was posted sees a visual indicator on their next visit, without any server request being made to track readership.
|
||||
- **SC-002**: After the event page is rendered, the same guest sees no indicator on their next visit (indicator clears after viewing).
|
||||
- **SC-003**: A first-time visitor to an event page with existing updates sees no "new" indicator.
|
||||
- **SC-004**: No network request is sent to the server when the read state transitions from unread to read.
|
||||
- **SC-005**: The read-state mechanism is independent of US-9's field-change highlight mechanism — toggling one does not affect the other.
|
||||
@@ -1,60 +0,0 @@
|
||||
# Feature Specification: Generate a QR Code for an Event
|
||||
|
||||
**Feature**: `017-qr-code`
|
||||
**Created**: 2026-03-06
|
||||
**Status**: Draft
|
||||
**Source**: Migrated from spec/userstories.md
|
||||
|
||||
## User Scenarios & Testing
|
||||
|
||||
### User Story 1 - Display and Download QR Code (Priority: P1)
|
||||
|
||||
Any visitor who holds the event link can view a QR code on the event page that encodes the public event URL. The QR code is generated server-side — no external service is contacted — and can be downloaded as a print-ready file (SVG or high-resolution PNG). This makes it easy to print the code on posters or flyers.
|
||||
|
||||
**Why this priority**: This is the core deliverable of US-11. Without a downloadable, server-generated QR code, the feature has no value. All other criteria are conditions of this baseline.
|
||||
|
||||
**Independent Test**: Can be fully tested by loading any event page and verifying that a QR code is displayed, that a download link produces a valid SVG or PNG file whose content encodes the correct event URL, and that no external network request was made to generate it.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a valid event exists, **When** a visitor opens the event page, **Then** a QR code encoding the public event URL is displayed on the page.
|
||||
2. **Given** a QR code is displayed, **When** the visitor clicks the download link, **Then** a file (SVG or high-resolution PNG) is downloaded directly from the app's backend without client-side generation.
|
||||
3. **Given** the downloaded file, **When** it is scanned with a QR reader, **Then** it resolves to the correct public event URL.
|
||||
4. **Given** the QR code endpoint is accessed, **When** the server generates the code, **Then** no request is made to any external QR code service.
|
||||
5. **Given** a visitor who has not RSVPed or logged in, **When** they access the event page, **Then** the QR code and download link are still available — no organizer token or RSVP required.
|
||||
6. **Given** the event has expired, **When** a visitor opens the event page, **Then** the QR code and download link remain available and functional.
|
||||
7. **Given** the QR code download is requested, **When** the server handles the request, **Then** no personal data, IP address, or identifier is transmitted to any third party.
|
||||
|
||||
---
|
||||
|
||||
### Edge Cases
|
||||
|
||||
- What happens when the event does not exist? The server returns "event not found" — the QR code endpoint must behave consistently and not leak data.
|
||||
- How does the download link behave when the event URL is long? The QR code must be generated at sufficient error-correction level to remain scannable even for longer URLs.
|
||||
|
||||
## Requirements
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-001**: The event page MUST display a QR code that encodes the public event URL.
|
||||
- **FR-002**: The QR code MUST be generated entirely server-side — no external QR code service or third-party API may be contacted.
|
||||
- **FR-003**: The QR code MUST be downloadable as a file suitable for printing (SVG or high-resolution PNG).
|
||||
- **FR-004**: The QR code download MUST be served from a direct backend endpoint — the actual file download MUST NOT require client-side generation.
|
||||
- **FR-005**: The QR code MUST be accessible to any visitor holding the event link; no organizer token or RSVP is required.
|
||||
- **FR-006**: No personal data, IP address, or identifier MUST be transmitted to any third party when the QR code is generated or downloaded.
|
||||
- **FR-007**: The QR code MUST remain available and downloadable after the event has expired.
|
||||
- **FR-008**: The QR code endpoint MUST return a consistent "event not found" response if the event does not exist — no partial data or error traces may be exposed.
|
||||
|
||||
### Key Entities
|
||||
|
||||
- **QRCode**: Virtual — no independent storage. Generated on demand from the event token and the public event URL. Not persisted.
|
||||
|
||||
## Success Criteria
|
||||
|
||||
### Measurable Outcomes
|
||||
|
||||
- **SC-001**: A visitor can view a QR code on any event page without performing any additional action (no login, no RSVP).
|
||||
- **SC-002**: The downloaded file scans correctly to the event URL in at least two independent QR reader applications.
|
||||
- **SC-003**: No outbound network request to an external service is made during QR code generation (verifiable via network inspection).
|
||||
- **SC-004**: The QR code endpoint returns a valid file for both active and expired events.
|
||||
- **SC-005**: The download link works without JavaScript (direct server endpoint).
|
||||
@@ -1,90 +0,0 @@
|
||||
# Feature Specification: Automatic Data Deletion After Expiry Date
|
||||
|
||||
**Feature**: `018-data-deletion`
|
||||
**Created**: 2026-03-06
|
||||
**Status**: Draft
|
||||
**Source**: Migrated from spec/userstories.md
|
||||
|
||||
## User Scenarios & Testing
|
||||
|
||||
### User Story 1 - Automatic cleanup of expired event data (Priority: P1)
|
||||
|
||||
As a guest, I want all event data — including my RSVP and any other stored personal information — to be automatically and permanently deleted after the event's expiry date, so that I can trust that data I submitted is not retained on the server longer than necessary.
|
||||
|
||||
**Why this priority**: This is a privacy guarantee, not merely a housekeeping task. The mandatory expiry date in US-1 is only meaningful if the server actually enforces deletion. Without this story, the expiry date is a lie.
|
||||
|
||||
**Independent Test**: Can be tested by creating an event with a near-future expiry date, submitting an RSVP, waiting for expiry, and verifying that the event's public URL returns "event not found" and no data remains accessible.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** an event whose expiry date has passed, **When** the cleanup process runs, **Then** the event record and all associated data (RSVPs, update messages, field-change metadata, header images, cancellation state) are permanently deleted from the server.
|
||||
2. **Given** an event that has been deleted by the cleanup process, **When** a guest navigates to the event's public URL, **Then** the server returns a clear "event not found" response with no partial data or error traces.
|
||||
3. **Given** a deletion event, **When** the cleanup process deletes data, **Then** no log entry records the names, RSVPs, or any personal data of the deleted event's guests — the deletion is silent from a logging perspective.
|
||||
4. **Given** the cleanup process, **When** it runs, **Then** it runs automatically without manual operator intervention (e.g. via a scheduled job or on-request lazy cleanup triggered by access attempts).
|
||||
|
||||
---
|
||||
|
||||
### User Story 2 - Expiry date extension delays deletion (Priority: P2)
|
||||
|
||||
As an event organizer, I want to be able to extend the expiry date of my event (via US-5) and have the deletion be deferred accordingly, so that I can keep my event data available for longer when needed.
|
||||
|
||||
**Why this priority**: Ensures US-5 (edit expiry date) and US-12 (deletion) work together correctly — the cleanup must always use the current stored expiry date, not the original one.
|
||||
|
||||
**Independent Test**: Can be tested by creating an event, extending its expiry date before expiry passes, and verifying that the event data is not deleted until the new expiry date.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** an event whose expiry date was extended via US-5 before the original expiry passed, **When** the cleanup process runs after the original date but before the new date, **Then** the event data is not deleted.
|
||||
2. **Given** an event whose expiry date was extended, **When** the new expiry date passes and the cleanup process runs, **Then** the event and all associated data are deleted.
|
||||
|
||||
---
|
||||
|
||||
### User Story 3 - Cleanup does not trigger early (Priority: P2)
|
||||
|
||||
As a guest, I want my event data to be retained until the expiry date has fully passed, so that I can access the event page right up until expiry without unexpected data loss.
|
||||
|
||||
**Why this priority**: Ensures correctness — data must not be deleted prematurely.
|
||||
|
||||
**Independent Test**: Can be tested by verifying that an event with an expiry date set to tomorrow remains fully accessible today.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** an event whose expiry date is today but has not yet passed, **When** a guest accesses the event page, **Then** the event data is still served normally.
|
||||
2. **Given** an event whose expiry date passed yesterday, **When** the cleanup process runs, **Then** the event and all associated data are deleted.
|
||||
|
||||
---
|
||||
|
||||
### Edge Cases
|
||||
|
||||
- What happens if the cleanup process fails mid-run (e.g. server crash)? The next run must safely re-attempt deletion without corrupting partial state.
|
||||
- What happens if multiple cleanup runs overlap? The process must be idempotent — deleting an already-deleted event must not cause errors.
|
||||
- LocalStorage entries on guests' devices are unaffected by server-side deletion — this is intentional. The app handles the "event not found" response gracefully (US-2, US-7).
|
||||
- If a stored header image file is missing on disk at deletion time (e.g. corrupted storage), the cleanup must still complete and delete the database record.
|
||||
|
||||
## Requirements
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-001**: The server MUST run a periodic cleanup process that automatically deletes all data associated with events whose expiry date has passed.
|
||||
- **FR-002**: The cleanup MUST delete the event record along with all associated data: RSVPs, update messages (US-10a), field-change metadata (US-9), stored header images (US-16) [deferred until US-16 is implemented], and cancellation state (US-18 if applicable).
|
||||
- **FR-003**: After deletion, the event's public URL MUST return a clear "event not found" response — no partial data is ever served.
|
||||
- **FR-004**: The cleanup process MUST run automatically without manual operator intervention (e.g. a scheduled job, Spring `@Scheduled`, or on-request lazy cleanup triggered by access attempts).
|
||||
- **FR-005**: The cleanup MUST NOT log the names, RSVPs, or any personal data of deleted events — deletion is silent from a logging perspective.
|
||||
- **FR-006**: The cleanup MUST always use the current stored expiry date when determining whether an event is eligible for deletion — extending the expiry date via US-5 before expiry passes delays deletion accordingly.
|
||||
- **FR-007**: The cleanup MUST NOT be triggered early — data is retained until the expiry date has passed, not before.
|
||||
- **FR-008**: The cleanup process MUST be idempotent — re-running it against already-deleted events must not cause errors.
|
||||
|
||||
### Key Entities
|
||||
|
||||
- **Event (expiry_date)**: The `expiry_date` field on the Event entity determines when the event becomes eligible for deletion. It is updated by US-5 (edit event details).
|
||||
- **Cleanup Job**: A background process (not a user-facing entity) responsible for identifying and deleting expired events and all their associated data.
|
||||
|
||||
## Success Criteria
|
||||
|
||||
### Measurable Outcomes
|
||||
|
||||
- **SC-001**: An event with a passed expiry date returns "event not found" from the server within one cleanup cycle of the expiry.
|
||||
- **SC-002**: All associated data (RSVPs, update messages, metadata, images) is deleted atomically with the event record — no orphaned records remain after a successful cleanup run.
|
||||
- **SC-003**: No PII (names, RSVP choices) appears in server logs during or after the deletion process.
|
||||
- **SC-004**: Extending an event's expiry date via US-5 correctly defers deletion — verified by querying the database after the original expiry would have triggered cleanup.
|
||||
- **SC-005**: The cleanup process completes successfully even if a stored header image file is missing on disk (resilient to partial storage failures).
|
||||
@@ -1,88 +0,0 @@
|
||||
# Feature Specification: Limit Active Events Per Instance
|
||||
|
||||
**Feature**: `019-instance-limit`
|
||||
**Created**: 2026-03-06
|
||||
**Status**: Draft
|
||||
**Source**: Migrated from spec/userstories.md (US-13)
|
||||
|
||||
## User Scenarios & Testing
|
||||
|
||||
### User Story 1 - Enforce Configured Event Cap on Creation (Priority: P1)
|
||||
|
||||
As a self-hoster, I want to configure a maximum number of simultaneously active events via a server environment variable, so that I can prevent storage exhaustion and limit potential abuse on my instance without modifying code.
|
||||
|
||||
**Why this priority**: The event cap is the primary deliverable of this story — without it, there is no feature. All other scenarios are edge cases of this core enforcement behavior.
|
||||
|
||||
**Independent Test**: Can be fully tested by configuring `MAX_ACTIVE_EVENTS=1`, creating one event, then attempting to create a second — the second creation should be rejected with a clear error.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** the server is configured with `MAX_ACTIVE_EVENTS=3` and 3 non-expired events exist, **When** a user submits the event creation form, **Then** the server rejects the request with a clear error indicating the instance is at capacity, and the frontend surfaces this error on the creation form — not as a silent failure.
|
||||
2. **Given** the server is configured with `MAX_ACTIVE_EVENTS=3` and 2 non-expired events exist, **When** a user submits the event creation form, **Then** the request succeeds and the new event is created normally.
|
||||
3. **Given** the server is configured with `MAX_ACTIVE_EVENTS=3` and 3 non-expired events exist, but 1 is past its expiry date (awaiting cleanup), **When** a user submits the event creation form, **Then** the request succeeds — expired events do not count toward the limit.
|
||||
|
||||
---
|
||||
|
||||
### User Story 2 - No Limit When Variable Is Unset (Priority: P2)
|
||||
|
||||
As a self-hoster running a personal or trusted-group instance, I want no event limit applied by default, so that I do not need to configure anything to run the app normally.
|
||||
|
||||
**Why this priority**: The default behavior (unlimited) must be safe and require no configuration. Self-hosters who do not need a cap should not have to think about this setting.
|
||||
|
||||
**Independent Test**: Can be fully tested by starting the server without `MAX_ACTIVE_EVENTS` set and verifying that multiple events can be created without rejection.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** the server has no `MAX_ACTIVE_EVENTS` environment variable set, **When** any number of events are created, **Then** no capacity error is returned — event creation is unlimited.
|
||||
2. **Given** the server has `MAX_ACTIVE_EVENTS` set to an empty string, **When** events are created, **Then** no capacity error is returned — an empty value is treated the same as unset.
|
||||
|
||||
---
|
||||
|
||||
### User Story 3 - Cap Is Enforced Server-Side Only (Priority: P2)
|
||||
|
||||
As a self-hoster, I want the event cap to be enforced exclusively on the server, so that it cannot be bypassed by a modified or malicious client.
|
||||
|
||||
**Why this priority**: Client-side enforcement alone would be trivially bypassable. The server is the authoritative enforcement point.
|
||||
|
||||
**Independent Test**: Can be fully tested by sending a direct HTTP POST to the event creation endpoint (bypassing the frontend entirely) when the cap is reached — the server must reject it.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** the configured cap is reached, **When** a direct HTTP POST is made to the event creation endpoint (bypassing the frontend), **Then** the server returns an error response indicating the instance is at capacity.
|
||||
2. **Given** the configured cap is reached, **When** no personal data is included in the rejection response or logs, **Then** the server returns only the rejection status — no PII is logged.
|
||||
|
||||
---
|
||||
|
||||
### Edge Cases
|
||||
|
||||
- What happens when `MAX_ACTIVE_EVENTS=0`? [NEEDS EXPANSION — treat as "no limit" or "reject all"? Clarify during implementation.]
|
||||
- What happens when `MAX_ACTIVE_EVENTS` is set to a non-integer value? The server should fail fast at startup with a clear configuration error.
|
||||
- Race condition: two concurrent creation requests when the cap is at N-1. The server must handle this atomically — one request succeeds, the other is rejected.
|
||||
- Expired events that have not yet been cleaned up must not count toward the limit. The check must query only non-expired events.
|
||||
|
||||
## Requirements
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-001**: The server MUST read a `MAX_ACTIVE_EVENTS` environment variable at startup to determine the event creation cap.
|
||||
- **FR-002**: If `MAX_ACTIVE_EVENTS` is set to a positive integer and the number of non-expired events equals or exceeds that value, the server MUST reject new event creation requests with a clear error response.
|
||||
- **FR-003**: The frontend MUST surface the capacity error on the event creation form — not as a silent failure or generic error.
|
||||
- **FR-004**: If `MAX_ACTIVE_EVENTS` is unset or empty, the server MUST apply no limit — event creation is unlimited.
|
||||
- **FR-005**: Only non-expired events MUST count toward the limit; expired events awaiting cleanup are excluded from the count.
|
||||
- **FR-006**: The limit MUST be enforced server-side; client-side state or input cannot bypass it.
|
||||
- **FR-007**: No personal data or PII MUST be logged when a creation request is rejected due to the cap.
|
||||
- **FR-008**: The `MAX_ACTIVE_EVENTS` environment variable MUST be documented in the README's self-hosting section (configuration table).
|
||||
|
||||
### Key Entities
|
||||
|
||||
- **Event (active count)**: The count of events whose `expiry_date` is in the future. This is the value checked against `MAX_ACTIVE_EVENTS` at event creation time.
|
||||
|
||||
## Success Criteria
|
||||
|
||||
### Measurable Outcomes
|
||||
|
||||
- **SC-001**: When the cap is reached, a POST to the event creation endpoint returns an appropriate HTTP error status with a machine-readable error body.
|
||||
- **SC-002**: The capacity error is displayed to the user on the creation form with a message that does not expose internal state or configuration values.
|
||||
- **SC-003**: Creating events up to but not exceeding the cap succeeds without any change in behavior compared to uncapped instances.
|
||||
- **SC-004**: The `MAX_ACTIVE_EVENTS` variable appears in the README configuration table with its type, default, and description documented.
|
||||
- **SC-005**: Expired events (past `expiry_date`) are never counted toward the cap, verifiable by inspecting the query or checking behavior after expiry.
|
||||
@@ -1,73 +0,0 @@
|
||||
# Feature Specification: Install as Progressive Web App
|
||||
|
||||
**Feature**: `020-pwa`
|
||||
**Created**: 2026-03-06
|
||||
**Status**: Draft
|
||||
**Source**: Migrated from spec/userstories.md
|
||||
|
||||
## User Scenarios & Testing
|
||||
|
||||
### User Story 1 - Install the app on a mobile or desktop device (Priority: P1)
|
||||
|
||||
**As a** guest,
|
||||
**I want to** install the app on my device from the browser,
|
||||
**so that** it feels like a native app and I can launch it directly from my home screen.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** the app is open in a supported mobile browser, **When** the user opens the browser menu, **Then** an "Add to Home Screen" or install prompt is available because the app serves a valid manifest and a registered service worker.
|
||||
|
||||
2. **Given** the user has installed the app, **When** they launch it from the home screen, **Then** the app opens in standalone mode — without browser address bar or navigation chrome.
|
||||
|
||||
3. **Given** the app is installed, **When** the user views their device's home screen or app switcher, **Then** the configured icon and app name are displayed.
|
||||
|
||||
4. **Given** the user has visited the app previously, **When** they open the app again (including on a slow or offline connection), **Then** previously loaded pages and assets load quickly due to service worker caching.
|
||||
|
||||
5. **Given** the app is installed and launched from the home screen, **When** the app starts, **Then** the start URL is the root page (`/`), which serves the local event overview (US-7), so returning users see their tracked events immediately.
|
||||
|
||||
### User Story 2 - Serve a valid web app manifest (Priority: P1)
|
||||
|
||||
**As a** browser,
|
||||
**I want** the app to serve a well-formed web app manifest,
|
||||
**so that** I can offer the user an install prompt and render the installed app correctly.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a browser fetches the app's manifest, **Then** it includes at minimum: app name, icons in multiple sizes, standalone display mode, theme color, and a start URL.
|
||||
|
||||
2. **Given** the manifest and service worker are present, **Then** the app meets browser installability requirements (manifest + registered service worker) so that the install prompt is available on supported browsers.
|
||||
|
||||
3. **Given** the manifest or service worker loads assets, **Then** no external resources are fetched — all assets referenced are self-hosted.
|
||||
|
||||
### Edge Cases
|
||||
|
||||
- Browsers that do not support service workers or PWA installation should still render the app normally — PWA features are an enhancement, not a requirement.
|
||||
- If the service worker fails to install (e.g. due to a browser policy), the app must still function as a standard web page.
|
||||
- Service worker caching strategy (cache-first, network-first, stale-while-revalidate) is an implementation decision to be determined during implementation.
|
||||
|
||||
## Requirements
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-01**: The app serves a valid web app manifest (JSON) accessible at a standard path (e.g. `/manifest.webmanifest` or `/manifest.json`).
|
||||
- **FR-02**: The manifest includes at minimum: app name, short name, icons in multiple sizes (e.g. 192x192 and 512x512), `display: "standalone"`, `theme_color`, `background_color`, and `start_url: "/"`.
|
||||
- **FR-03**: The app registers a service worker that meets browser installability requirements alongside the manifest.
|
||||
- **FR-04**: When launched from the home screen, the app opens in standalone mode without browser navigation chrome.
|
||||
- **FR-05**: The app icon and name are shown on the device home screen and in the OS app switcher after installation.
|
||||
- **FR-06**: The service worker caches app assets so that repeat visits load quickly.
|
||||
- **FR-07**: The manifest's start URL is `/`, serving the local event overview (US-7).
|
||||
- **FR-08**: No external resources (CDNs, external fonts, remote icons) are fetched by the manifest or service worker — all assets are self-hosted.
|
||||
- **FR-09**: PWA installability does not depend on any backend state — it is a purely frontend concern served by the static assets.
|
||||
|
||||
### Key Entities
|
||||
|
||||
- **Web App Manifest**: A static JSON file describing the app's identity, icons, display mode, and start URL. No database storage required.
|
||||
- **Service Worker**: A client-side script registered by the app to handle caching and (optionally) offline behavior. No server-side representation.
|
||||
|
||||
## Success Criteria
|
||||
|
||||
1. A supported mobile browser shows an "Add to Home Screen" prompt or install banner for the app.
|
||||
2. After installation, the app launches in standalone mode with the correct icon and name.
|
||||
3. The installed app's start URL leads directly to the local event overview (`/`).
|
||||
4. Repeat visits are noticeably faster due to service worker asset caching.
|
||||
5. No external resources are loaded by the manifest or service worker — all assets are served from the app's own origin.
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user