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>
3.1 KiB
3.1 KiB
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 inEventList.vuewith 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
deleteDialogMessageanddeleteDialogTitlebased ongetRole(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
titleandmessageprops. ThedeleteDialogMessagecomputed 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.