first pass at tintegrating email campaigns

Author: antonisloizou

README.md

@@ -13,11 +13,12 @@ Create a single source of truth for operational data that keeps the team synchro
 - Event-level commercial registration settings including public signup toggles, deadlines, pricing, currency, and confirmation thresholds.
 - Public event registration pages by slug that create participant-linked registrations and default payment placeholders.
 - Staff registration operations pages for event-level registration lists, status changes, payment updates, and internal notes.
+- Event comms pages with reusable email templates, audience preview by registration/payment filters, manual campaign send, and delivery history.
 - Safety and compliance fields on events/innhopps (NOTAM, risk assessment, safety precautions).
 - RBAC-backed login sessions (OIDC) with seeded roles for core operational duties.
 
 ## Not yet implemented
-- Automated notifications and campaign email sending.
+- Automated notifications with background scheduling and real provider delivery.
 - Payment provider integrations, waivers, certifications, and health declarations.
 - Check-in flows or public driver route pages.
 - Analytics dashboards beyond raw data access.
@@ -50,6 +51,7 @@ RBAC ensures each user only sees the modules and actions needed for their duties
 - Configure event registration settings such as public slug, opening windows, balance deadlines, pricing, and minimum registration thresholds.
 - Share public `/register/:slug` links, accept self-serve signups, auto-create or match participant profiles by email, and generate deposit/balance payment placeholders from the event settings.
 - Open `/events/:eventId/registrations` to filter registrations by status and payment state, then drill into `/registrations/:registrationId` to update deadlines, payment records, status, and activity notes.
+- Open `/events/:eventId/comms` to create email templates, preview recipients for an event, send a manual campaign to filtered registrations, and review send history.
 - Coordinate transports, vehicles, accommodations, meals, and other logistics items per operation.
 - Authenticate via OIDC (authorization code flow), persist sessions in secure cookies, and enforce role-based permissions seeded on startup (Admin, Staff, Jump Master, Jump Leader, Ground Crew, Driver, Packer, Participant). Set `DEV_ALLOW_ALL=true` to bypass auth locally.
 - Use the frontend pages for login, events, manifests, participants, logistics, seasons, innhopp details, and airfield details (see `frontend/src/pages/` and `frontend/src/components/Layout.tsx` for the routes).
@@ -119,4 +121,4 @@ Frontend environment variables:
 
 ## API and UI references
 - Backend endpoints for seasons, events, innhopps, manifests, airfields, participants, registrations, crew assignments, logistics transports, and auth are documented in `backend/README.md`.
-- Frontend routes include `/login`, `/register/:slug`, `/events`, `/events/:eventId`, `/events/:eventId/details`, `/events/:eventId/registrations`, `/registrations/:registrationId`, `/events/:eventId/innhopps/:innhoppId`, `/manifests`, `/manifests/:manifestId`, `/participants`, `/participants/:participantId`, `/logistics`, `/airfields/:airfieldId`, plus creation flows for seasons, events, manifests, and participants.
+- Frontend routes include `/login`, `/register/:slug`, `/events`, `/events/:eventId`, `/events/:eventId/details`, `/events/:eventId/registrations`, `/events/:eventId/comms`, `/registrations/:registrationId`, `/events/:eventId/innhopps/:innhoppId`, `/manifests`, `/manifests/:manifestId`, `/participants`, `/participants/:participantId`, `/logistics`, `/airfields/:airfieldId`, plus creation flows for seasons, events, manifests, and participants.

backend/README.md

@@ -39,6 +39,9 @@ On startup the server creates these tables if they do not already exist:
 - `event_registrations` – participant-to-event lifecycle records with deadlines, notes, and ownership.
 - `registration_payments` – ledger entries for deposit, balance, refund, and manual adjustments per registration.
 - `registration_activity` – internal timeline entries attached to a registration.
+- `email_templates` – reusable subject/body templates for event communications.
+- `email_campaigns` – manual or automated campaign executions with stored audience filters.
+- `email_deliveries` – rendered outbound messages logged per recipient and campaign.
 - `crew_assignments` – role assignments for a participant on a manifest.
 - `gear_assets` – tracked gear inventory with inspection status.
 
@@ -108,6 +111,12 @@ On startup the server creates these tables if they do not already exist:
 | POST | `/api/registrations/{registrationID}/payments` | Create a payment ledger row |
 | PUT | `/api/registrations/payments/{paymentID}` | Update a payment ledger row |
 | POST | `/api/registrations/{registrationID}/activity` | Append an internal activity entry |
+| GET | `/api/comms/templates` | List email templates |
+| POST | `/api/comms/templates` | Create an email template |
+| GET | `/api/comms/events/{eventID}/audience-preview` | Preview comms recipients for an event with status/payment filters |
+| GET | `/api/comms/events/{eventID}/campaigns` | List campaign history for an event |
+| POST | `/api/comms/campaigns` | Create and send a manual campaign |
+| GET | `/api/comms/campaigns/{campaignID}` | Retrieve one campaign with delivery log |
 | GET | `/api/rbac/crew-assignments` | List crew assignments |
 | POST | `/api/rbac/crew-assignments` | Create a crew assignment |
 | GET | `/api/logistics/gear-assets` | List gear assets |
@@ -121,6 +130,7 @@ On startup the server creates these tables if they do not already exist:
 - The registration backbone enforces one active registration per participant per event; cancelled or expired registrations can be recreated.
 - Public registration links only work for events with `public_registration_enabled=true`; the backend also respects `registration_open_at` and rejects registrations after the event start time.
 - Public registrations match existing participants by normalized email or create a new participant profile, then create deposit/balance payment rows from the event commercial settings.
+- The first comms slice renders templates and logs per-recipient deliveries inside the database; it does not yet integrate an SMTP/provider transport or background scheduler.
 
 ## Testing