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