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.