Files
Salon/docs/execplans/booking-notifications.md

44 lines
1.6 KiB
Markdown

# Booking Lifecycle Notifications
This ExecPlan follows `docs/PLANS.md`.
## Purpose / Big Picture
Notify customer and staff on booking created/confirmed/cancelled with auditable notification rows.
## Progress
- [x] (2026-02-28 17:05Z) Plan + scope finalized.
- [x] (2026-02-28 17:40Z) Notification app + providers + booking wiring implemented.
- [x] (2026-02-28 18:05Z) Tests added for create/status-change/no-duplicate behavior.
- [x] (2026-02-28 18:10Z) Risks/docs updated.
## Surprises & Discoveries
- Observation: status field had been read-only for update flow.
Evidence: `PATCH /api/bookings/<id>` validation failure before serializer update.
## Decision Log
- Decision: persist notification records for every lifecycle send attempt.
Rationale: auditability + support traceability.
Date/Author: 2026-02-28/Codex
- Decision: reuse OTP provider abstraction for notification channels.
Rationale: avoid duplicated provider integration.
Date/Author: 2026-02-28/Codex
## Outcomes & Retrospective
Completed. Booking lifecycle notifications are live with idempotent records and test coverage.
## Context and Orientation
- Notification domain: `backend/apps/notifications/`
- Booking integration points: `backend/apps/bookings/views.py`
## Plan of Work
Completed; future work is provider hardening/monitoring only.
## Validation and Acceptance
From `backend/`:
- `python3 -m pytest backend/apps/notifications/tests`
Acceptance:
- Create/confirm/cancel each emit customer+staff notification rows once per event/channel.
## Idempotence and Recovery
Uniqueness constraints prevent duplicate event/channel sends per recipient/booking; retries update existing rows safely.