# Tasks: Cancel Event

**Input**: Design documents from `/specs/016-cancel-event/`
**Prerequisites**: plan.md, spec.md, research.md, data-model.md, contracts/patch-event-endpoint.yaml

**Tests**: Included — constitution mandates TDD (tests before implementation) and E2E for every frontend user story.

**Organization**: Tasks grouped by user story. Both stories are P1 but US2 depends on US1's backend work.

## Format: `[ID] [P?] [Story] Description`

- **[P]**: Can run in parallel (different files, no dependencies)
- **[Story]**: Which user story this task belongs to (e.g., US1, US2)
- Include exact file paths in descriptions

---

## Phase 1: Setup (Shared Infrastructure)

**Purpose**: OpenAPI spec, database migration, and domain model changes that both user stories depend on.

- [ ] T001 Update OpenAPI spec with PATCH endpoint on `/events/{eventToken}`, PatchEventRequest schema (`organizerToken`, `cancelled`, `cancellationReason`), and extend GetEventResponse with `cancelled`/`cancellationReason` fields in `backend/src/main/resources/openapi/api.yaml`
- [ ] T002 Add Liquibase changeset 004 adding `cancelled` (BOOLEAN NOT NULL DEFAULT FALSE) and `cancellation_reason` (VARCHAR 2000) columns to `events` table in `backend/src/main/resources/db/changelog/004-add-cancellation-columns.xml` and register it in `db.changelog-master.xml`
- [ ] T003 [P] Extend domain model `Event.java` with `cancelled`, `cancellationReason` fields and `cancel(String reason)` method (throws `EventAlreadyCancelledException`). Create `EventAlreadyCancelledException` in `backend/src/main/java/de/fete/application/service/` following the pattern of existing exceptions. Domain model: `backend/src/main/java/de/fete/domain/model/Event.java`
- [ ] T004 [P] Extend JPA entity `EventJpaEntity.java` with `cancelled` and `cancellation_reason` columns and update mapper in `backend/src/main/java/de/fete/adapter/out/persistence/EventJpaEntity.java`
- [ ] T005 Regenerate frontend TypeScript types from updated OpenAPI spec via `cd frontend && npm run generate-types` (or equivalent openapi-typescript command)

**Checkpoint**: Schema, migration, and domain model ready. Both user stories can now proceed.

---

## Phase 2: User Story 1 — Organizer Cancels an Event (Priority: P1) MVP

**Goal**: Organizer can cancel an event via a bottom sheet with optional reason. Cancellation is irreversible and persists on reload.

**Independent Test**: View event with organizer token, tap cancel, optionally enter reason, confirm. Event remains cancelled on reload.

### Tests for User Story 1

> **Write these tests FIRST — ensure they FAIL before implementation**

- [ ] T006 [P] [US1] Write unit test for `cancel()` domain method (happy path, already-cancelled throws) in `backend/src/test/java/de/fete/domain/model/EventTest.java`
- [ ] T007 [P] [US1] Write unit test for cancel use case in EventService (delegates to domain, saves, 403/404/409 cases) in `backend/src/test/java/de/fete/application/service/EventServiceCancelTest.java`
- [ ] T008 [P] [US1] Write integration test for `PATCH /events/{eventToken}` endpoint (204 success, 403 wrong token, 404 not found, 409 already cancelled) in `backend/src/test/java/de/fete/adapter/in/web/EventControllerCancelTest.java`
- [ ] T009 [P] [US1] Write E2E test: organizer opens cancel bottom sheet, enters reason, confirms — event shows as cancelled on reload in `frontend/e2e/cancel-event.spec.ts`
- [ ] T010 [P] [US1] Write E2E test: organizer cancels without reason — event shows as cancelled in `frontend/e2e/cancel-event.spec.ts`
- [ ] T011 [P] [US1] Write E2E test: cancel API fails — error displayed in bottom sheet, button re-enabled for retry in `frontend/e2e/cancel-event.spec.ts`

### Implementation for User Story 1

- [ ] T012 [US1] Create `CancelEventUseCase` interface (or add method to existing use case interface) in `backend/src/main/java/de/fete/domain/port/in/`
- [ ] T013 [US1] Implement cancel logic in `EventService.java` — load event, verify organizer token, call `event.cancel(reason)`, persist in `backend/src/main/java/de/fete/application/service/EventService.java`
- [ ] T014 [US1] Implement `cancelEvent` endpoint in `EventController.java` — PATCH handler, request body binding, error mapping (403/404/409) in `backend/src/main/java/de/fete/adapter/in/web/EventController.java`
- [ ] T015 [US1] Add cancel button (visible only when organizer token exists and event not cancelled — covers FR-012) and cancel bottom sheet (textarea with 2000 char limit + confirm button + inline error) to `frontend/src/views/EventDetailView.vue`
- [ ] T016 [US1] Wire cancel bottom sheet confirm action to `PATCH /events/{eventToken}` API call via openapi-fetch, handle success (reload event data) and error (show inline message, re-enable button) in `frontend/src/views/EventDetailView.vue`

**Checkpoint**: Organizer can cancel an event. All US1 acceptance scenarios pass.

---

## Phase 3: User Story 2 — Attendee Sees Cancelled Event (Priority: P1)

**Goal**: Visitors see a prominent red cancellation banner on cancelled events. RSVP buttons are hidden. All other event details remain visible.

**Independent Test**: View a cancelled event's detail page — banner visible (with reason if provided), RSVP buttons hidden, other details intact.

### Tests for User Story 2

> **Write these tests FIRST — ensure they FAIL before implementation**

- [ ] T017 [P] [US2] Write unit test for RSVP creation rejection on cancelled events (409 Conflict) in `backend/src/test/java/de/fete/application/service/RsvpServiceCancelledTest.java`
- [ ] T018 [P] [US2] Write integration test for `POST /events/{eventToken}/rsvps` returning 409 when event is cancelled in `backend/src/test/java/de/fete/adapter/in/web/RsvpControllerCancelledTest.java`
- [ ] T019 [P] [US2] Write E2E test: visitor sees red banner with cancellation reason on cancelled event in `frontend/e2e/cancelled-event-visitor.spec.ts`
- [ ] T020 [P] [US2] Write E2E test: visitor sees red banner without reason when no reason was provided in `frontend/e2e/cancelled-event-visitor.spec.ts`
- [ ] T021 [P] [US2] Write E2E test: RSVP buttons hidden on cancelled event, other details remain visible in `frontend/e2e/cancelled-event-visitor.spec.ts`

### Implementation for User Story 2

- [ ] T022 [US2] Add cancelled-event guard to RSVP creation — check `event.isCancelled()`, return 409 Conflict in `backend/src/main/java/de/fete/application/service/RsvpService.java`
- [ ] T023 [US2] Add cancellation banner component/section (red, prominent, includes reason if present, WCAG AA contrast) to `frontend/src/views/EventDetailView.vue`
- [ ] T024 [US2] Hide RSVP buttons (`RsvpBar` or equivalent) when `event.cancelled === true` in `frontend/src/views/EventDetailView.vue`
- [ ] ~~T025~~ Merged into T015 (cancel button v-if already handles FR-012)

**Checkpoint**: Both user stories fully functional. All acceptance scenarios pass.

---

## Phase 4: Polish & Cross-Cutting Concerns

**Purpose**: Validation, edge cases, and final cleanup.

- [ ] T026 Verify cancellationReason max length (2000 chars) is enforced at API level (OpenAPI `maxLength`), domain level in `Event.java`, and UI level (textarea maxlength/counter)
- [ ] T027 Run full backend test suite (`cd backend && ./mvnw verify`) and fix any failures
- [ ] T028 Run full frontend test suite (`cd frontend && npm run test:unit`) and fix any failures
- [ ] T029 Run E2E tests (`cd frontend && npx playwright test`) and fix any failures
- [ ] T030 Run backend checkstyle (`cd backend && ./mvnw checkstyle:check`) and fix violations

---

## Dependencies & Execution Order

### Phase Dependencies

- **Setup (Phase 1)**: No dependencies — start immediately
- **US1 (Phase 2)**: Depends on Setup completion
- **US2 (Phase 3)**: Depends on Setup completion; backend RSVP guard is independent of US1, but frontend banner/hiding can be built in parallel with US1
- **Polish (Phase 4)**: Depends on all user stories complete

### User Story Dependencies

- **US1 (P1)**: Can start after Phase 1 (Setup). No dependency on US2.
- **US2 (P1)**: Can start after Phase 1 (Setup). Backend RSVP guard is independent of US1. Frontend banner/hiding only needs the `cancelled`/`cancellationReason` fields in GetEventResponse (from Setup).

### Within Each User Story

- Tests MUST be written and FAIL before implementation
- Domain model before service layer
- Service layer before controller/endpoint
- Backend before frontend (API must exist before UI wires to it)
- Core implementation before error handling polish

### Parallel Opportunities

- T003 + T004 (domain model + JPA entity) can run in parallel
- All US1 test tasks (T006–T011) can run in parallel
- All US2 test tasks (T017–T021) can run in parallel
- US1 backend (T012–T014) and US2 backend (T022) can run in parallel after Setup
- US1 frontend (T015–T016) and US2 frontend (T023–T025) can run in parallel if backend is ready

---

## Parallel Example: User Story 1

```bash
# Launch all US1 tests together (TDD - write first, expect failures):
Task: T006 "Unit test for cancel() domain method"
Task: T007 "Unit test for cancel use case in EventService"
Task: T008 "Integration test for PATCH /events/{eventToken}"
Task: T009 "E2E test: organizer cancels with reason"
Task: T010 "E2E test: organizer cancels without reason"
Task: T011 "E2E test: cancel API failure handling"

# Then implement sequentially:
Task: T012 "CancelEventUseCase interface"
Task: T013 "EventService cancel implementation"
Task: T014 "EventController cancelEvent endpoint"
Task: T015 "Cancel button + bottom sheet in EventDetailView"
Task: T016 "Wire cancel action to API"
```

---

## Implementation Strategy

### MVP First (User Story 1 Only)

1. Complete Phase 1: Setup (OpenAPI, migration, domain model)
2. Complete Phase 2: US1 — Organizer cancels event
3. **STOP and VALIDATE**: All US1 acceptance scenarios pass
4. Deploy/demo if ready — cancellation works end-to-end

### Incremental Delivery

1. Setup → Shared infrastructure ready
2. US1 → Organizer can cancel → Test → Deploy (MVP!)
3. US2 → Attendees see cancellation + RSVP blocked → Test → Deploy
4. Polish → Full verification, checkstyle, edge cases