fete/specs/025-delete-event/spec.md

Feature Specification: Delete an Event as Organizer

Feature: 025-delete-event Created: 2026-03-06 Status: Draft Source: Migrated from spec/userstories.md

User Scenarios & Testing

User Story 1 - Immediately delete an active event (Priority: P1)

The organizer wants to permanently remove an event they created — because it was a mistake, contains wrong information, or is no longer needed at all. From the organizer view, they trigger a dedicated "Delete event" action. After confirming a clear warning, the server immediately and permanently deletes all event data. The organizer is redirected to the root page and the event's local entry is removed.

Why this priority: This is the core action of the story. Without it, organizers have no manual removal mechanism — they can only wait for automatic expiry (US-12). It is the "nuclear option" that complements editing (US-5) and cancellation (US-18).

Independent Test: Can be tested by creating an event, navigating to the organizer view, triggering deletion, confirming the warning, and verifying the event URL returns "not found" and the root page no longer lists the event.

Acceptance Scenarios:

1. Given a valid organizer token is present in localStorage for an event, When the organizer triggers "Delete event" and confirms the warning, Then the server permanently deletes the event record and all associated data (RSVPs, update messages, field-change metadata, stored header images, cancellation state), and the event's public URL returns an "event not found" response.
2. Given deletion succeeds, When the server responds with success, Then the app removes the event's organizer token and metadata from localStorage and redirects the organizer to the root page (/).
3. Given the organizer view is open, When the organizer triggers "Delete event", Then a confirmation warning is shown that clearly states the action is immediate, permanent, and irreversible — all event data including RSVPs, update messages, and images will be lost.

---

User Story 2 - Delete a cancelled or expired event (Priority: P2)

The organizer wants to delete an event regardless of its current state — whether it is still active, already cancelled (US-18), or past its expiry date. Deletion must not be gated on event state.

Why this priority: Extending P1 to cover all event states. A cancelled event may have data the organizer wants removed immediately, without waiting for the expiry date.

Independent Test: Can be tested by cancelling an event (US-18), then triggering deletion from the organizer view and verifying that the deletion succeeds.

Acceptance Scenarios:

1. Given an event that has been cancelled (US-18), When the organizer confirms deletion, Then the server deletes the event and all its data, including the cancellation state, exactly as for an active event.
2. Given an event that has passed its expiry date but not yet been cleaned up by US-12, When the organizer confirms deletion, Then the deletion succeeds and the event is immediately removed.

---

User Story 3 - Reject deletion without a valid organizer token (Priority: P2)

A visitor without a valid organizer token must not be able to delete an event — the delete action is not shown to them and the server rejects any deletion request.

Why this priority: Security boundary. Without this, any visitor who knows the event token could delete the event.

Independent Test: Can be tested by attempting a DELETE request to the event endpoint without a valid organizer token and verifying the server rejects it with an appropriate error.

Acceptance Scenarios:

1. Given no organizer token is present in localStorage for a given event, When a visitor opens the event page, Then the delete action is not shown anywhere in the UI.
2. Given an organizer token is absent or invalid, When a DELETE request is sent to the server for that event, Then the server rejects the request and does not delete any data.

---

Edge Cases

• What happens if the organizer dismisses the confirmation warning? The deletion is aborted; no data is changed; the organizer remains on the event page.
• What happens if the network fails after confirmation but before the server responds? The event may or may not be deleted depending on whether the request reached the server. The app should display an error and not redirect; the organizer can retry.
• What happens if the organizer token in localStorage is valid but the event was already deleted (e.g. by US-12 cleanup between page load and deletion attempt)? The server returns "event not found"; the app should handle this gracefully and redirect to the root page, removing the stale localStorage entry.
• What if a stored header image file deletion fails during event deletion? The server must still delete the database record and must not leave the event in a partially-deleted state — image file cleanup failure should be logged server-side but must not abort deletion.

Requirements

Functional Requirements

• FR-001: The server MUST expose a DELETE endpoint for events, authenticated via the organizer token.
• FR-002: The server MUST permanently delete all associated data on deletion: RSVPs, update messages (US-10a), field-change metadata (US-9), stored header images (US-16), and cancellation state (US-18), in addition to the event record itself.
• FR-003: After deletion, the event's public URL MUST return an "event not found" response — no partial data may be served.
• FR-004: The frontend MUST show a confirmation warning before deletion, clearly stating that the action is immediate, permanent, and irreversible.
• FR-005: On successful deletion, the frontend MUST remove the event's organizer token and associated metadata from localStorage.
• FR-006: On successful deletion, the frontend MUST redirect the organizer to the root page (/).
• FR-007: The delete action MUST be accessible regardless of event state (active, cancelled, or expired).
• FR-008: If no valid organizer token is present, the delete action MUST NOT be shown in the UI and the server MUST reject the request.
• FR-009: No personal data or event data MUST be logged during deletion — deletion is silent from a logging perspective.

Key Entities

• Event: The primary entity being deleted. Deletion removes it and all child data (RSVPs, update messages, field-change metadata, images, cancellation state).
• OrganizerToken: The authentication credential (UUID) stored in localStorage and validated server-side. Required to authorize deletion.

Success Criteria

Measurable Outcomes

• SC-001: After deletion, a GET request to the event's public URL returns "event not found" — verifiable in an automated test immediately after deletion.
• SC-002: After deletion, no record of the event, its RSVPs, or its messages exists in the database — verifiable via database assertion in integration tests.
• SC-003: After deletion, the localStorage entry for the event (organizer token + metadata) is removed — verifiable in an E2E test.
• SC-004: A DELETE request without a valid organizer token is rejected by the server — verifiable in an automated API test.
• SC-005: The confirmation warning is always shown before deletion is triggered — verifiable in an E2E test by asserting the dialog appears before any data is sent to the server.