# TODO: Notification System via Email Inbound

**Date:** 2026-02-26  
**Status:** Idea — Ready for refinement  
**Priority:** Medium

---

## 🎯 Goal

Maak een notificatieflow waarbij collega's een email sturen naar `backups+notification@...`, waarna Backupchecks deze berichten ophaalt en de operator informeert in de applicatie (optioneel ook via email).

**Context:** Dit is een idee/TODO, nog geen implementatie.

---

## ✅ Idee samenvatting

### Gewenste werking

- Inkomende emails naar `backups+notification@...` worden periodiek opgehaald
- Relevante informatie uit onderwerp/body wordt omgezet naar een operator-notificatie
- Operator ziet ongelezen notificaties in Backupchecks
- Operator kan notificatie markeren als gelezen/afgehandeld
- Acties worden gelogd voor audit/doelmatige opvolging

---

## 🏗️ Architectuur richting

**Voorkeur:** Hergebruik van bestaande mail import pipeline

```
Mailbox Poller → Notification Parser → Operator Notification Store → UI Badge/Inbox
```

Rationale:
- Minder nieuwe infrastructuur nodig
- Consistent met bestaande email-gedreven verwerking in Backupchecks
- Sneller naar bruikbare MVP

---

## 🔧 Implementatie fases

### Phase 1: Database model
- [ ] Nieuwe tabel `operator_notifications` toevoegen
- [ ] Velden voor statusflow (`new`, `read`, `handled`) toevoegen
- [ ] Relatie naar operator (`operator_id`) toevoegen
- [ ] Optionele koppelingen naar `customer_id` en `job_id`

### Phase 2: Mail ingest
- [ ] Alias `backups+notification@...` opnemen in verwerking
- [ ] Alleen notificatie-mails verwerken voor dit kanaal
- [ ] Duplicate protectie op `message_id`
- [ ] Fallback voor berichten zonder bruikbare parse

### Phase 3: Parsing en prioriteit
- [ ] Subject/sender/body snippet opslaan
- [ ] Prioriteit bepalen (`normal`/`high`) op keywords zoals `urgent`, `critical`, `failed`
- [ ] Onveilige HTML strippen
- [ ] Max body size limiteren

### Phase 4: Operator UI
- [ ] Notificatie badge in hoofdlayout
- [ ] Operator notificatie-overzicht (inbox)
- [ ] Detailweergave met metadata
- [ ] Acties: markeren als gelezen en afgehandeld

### Phase 5: Settings en policy
- [ ] Instellingen voor mailbox alias
- [ ] Polling aan/uit + interval
- [ ] Sender allowlist (domeinen/adressen)
- [ ] Optie voor relay email naar operator

### Phase 6: Logging en audit
- [ ] Event `notification_created`
- [ ] Event `notification_read`
- [ ] Event `notification_handled`
- [ ] Afwijzingen van niet-toegestane afzenders loggen

---

## 📋 Data model (voorstel)

Nieuwe tabel: `operator_notifications`

- `id` (PK)
- `message_id` (unique, nullable fallback)
- `sender`
- `recipient`
- `subject`
- `body_text`
- `priority` (`normal` / `high`)
- `state` (`new` / `read` / `handled`)
- `operator_id` (FK users.id)
- `customer_id` (FK customers.id, nullable)
- `job_id` (FK jobs.id, nullable)
- `received_at`
- `created_at`
- `read_at` (nullable)
- `handled_at` (nullable)
- `handled_by` (FK users.id, nullable)

---

## ❓ Openstaande vragen

1. Wat is het exacte mailbox adres/domein voor `backups+notification@...`?
2. Moet notificatie routing naar alle operators, of naar een toegewezen operator per klant/job?
3. Is email relay naar operator verplicht voor MVP, of Nice to Have?
4. Wat is de bewaartermijn voor notificatie-inhoud?
5. Moeten attachments in fase 1 genegeerd blijven?

---

## 🎯 Success Criteria (MVP)

- [ ] Email naar `backups+notification@...` verschijnt binnen polling interval in Backupchecks
- [ ] Duplicates worden niet dubbel geïmporteerd
- [ ] Operator ziet ongelezen badge + details
- [ ] Operator kan notificatie afhandelen
- [ ] Niet-toegestane afzenders worden geweigerd en gelogd

### Nice to Have
- [ ] Automatische mapping naar klant/job via herkenning in onderwerp/body
- [ ] SLA timers op open notificaties
- [ ] Escalatie bij niet-opgevolgde high-priority notificaties