nitrix
b067c0ef1e
Organizers can now cancel events directly from the event list via the
existing PATCH /events/{eventToken} API. The confirmation dialog shows
role-differentiated messaging: "Cancel event?" with a severity warning
for organizers vs. "Remove event?" for attendees. Responses 204, 409,
and 404 all result in successful removal from the local list.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
40 lines
3.1 KiB
Markdown
40 lines
3.1 KiB
Markdown
# Research: Cancel Event from Event List
|
|
|
|
**Date**: 2026-03-12 | **Branch**: `018-cancel-event-list`
|
|
|
|
## Existing Cancel-Event API
|
|
|
|
- **Decision**: Reuse the existing `PATCH /events/{eventToken}?organizerToken=...` endpoint with `{ cancelled: true }` body.
|
|
- **Rationale**: The endpoint is fully implemented and documented in the OpenAPI spec. The EventDetailView already calls it successfully. No backend changes needed.
|
|
- **Alternatives considered**: None — the endpoint exists and fits the requirement exactly.
|
|
|
|
## EventList Delete Flow Architecture
|
|
|
|
- **Decision**: Extend the existing `confirmDelete()` handler in `EventList.vue` with a role-based branch: organizer → PATCH cancel-event, attendee → DELETE cancel-rsvp, watcher → direct remove.
|
|
- **Rationale**: The role detection (`getRole()`) already exists (lines 113-117). The current handler only covers attendee (RSVP deletion) and watcher (direct remove). Adding the organizer branch follows the same pattern.
|
|
- **Alternatives considered**: Creating a separate handler for organizer cancel — rejected because it would duplicate the dialog open/close and error handling logic.
|
|
|
|
## ConfirmDialog Message Differentiation
|
|
|
|
- **Decision**: Compute `deleteDialogMessage` and `deleteDialogTitle` based on `getRole(pendingDeleteEvent)`. Organizer gets a severe warning ("Cancel event? This will cancel the event for all attendees."), attendee keeps existing message.
|
|
- **Rationale**: The ConfirmDialog already accepts `title` and `message` props. The `deleteDialogMessage` computed property exists but currently only distinguishes RSVP vs watcher. Extend it to include organizer.
|
|
- **Alternatives considered**: Using a different dialog component for organizer — rejected (unnecessary, ConfirmDialog is sufficient and already styled with danger button).
|
|
|
|
## 409 Conflict Handling
|
|
|
|
- **Decision**: Treat 409 (event already cancelled) as success — silently remove event from local list.
|
|
- **Rationale**: Frontend does not track cancelled status. If the server says it's already cancelled, the user's intent (remove from list) is fulfilled either way.
|
|
- **Alternatives considered**: Showing an info message ("Event was already cancelled") — rejected per clarification session, silent removal is simpler and less confusing.
|
|
|
|
## In-Flight Behavior
|
|
|
|
- **Decision**: No loading indicator in ConfirmDialog. Dialog stays open until success (close + remove) or failure (stay open + error).
|
|
- **Rationale**: Consistent with all other ConfirmDialog-based flows in the project (cancel RSVP, delete event from list). The ConfirmDialog component has no loading state support and adding one would be scope creep.
|
|
- **Alternatives considered**: Adding `:disabled` + spinner to confirm button (like BottomSheet forms) — rejected for consistency with existing ConfirmDialog patterns.
|
|
|
|
## Confirm Button Styling
|
|
|
|
- **Decision**: Use `var(--color-danger-solid)` for the organizer cancel confirm button, consistent with existing ConfirmDialog danger styling.
|
|
- **Rationale**: The ConfirmDialog already uses danger-colored confirm buttons. No additional styling needed for the organizer flow.
|
|
- **Alternatives considered**: None — existing styling fits.
|