nitrix
6aeb4b8bca
- Move cross-cutting docs (personas, design system, implementation phases, Ideen.md) to .specify/memory/ - Move cross-cutting research and plans to .specify/memory/research/ and .specify/memory/plans/ - Extract 5 setup tasks from spec/setup-tasks.md into individual specs/001-005/spec.md files with spec-kit template format - Extract 20 user stories from spec/userstories.md into individual specs/006-026/spec.md files with spec-kit template format - Relocate feature-specific research and plan docs into specs/[feature]/ - Add spec-kit constitution, templates, scripts, and slash commands - Slim down CLAUDE.md to Claude-Code-specific config, delegate principles to .specify/memory/constitution.md - Update ralph.sh with stream-json output and per-iteration logging - Delete old spec/ and docs/agents/ directories - Gitignore Ralph iteration JSONL logs Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
75 lines
5.0 KiB
Markdown
75 lines
5.0 KiB
Markdown
# 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.
|