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