Benachrichtigungs-Abonnements
Zweck
Subscriptions (NotificationSubscription) verbinden wen (Kontakt oder SpeamBox) mit welchem Event-Typ und welchem Kanal. Beispiel: „Kontakt Frau Mueller bekommt bei Stoerung der SpeamBox BX-001 eine SMS und eine E-Mail" → zwei Subscriptions.
Voraussetzungen
Berechtigungen (CASL)
| Action | Subject | Keycloak-Rolle |
|---|---|---|
view | FE_NotificationSubscription, NotificationSubscription | — |
create/update/delete | NotificationSubscription | APP_SPEAMCORE_CREATE/UPDATE/DELETE_NOTIFICATION_SUBSCRIPTION |
view | Contact, Speambox, NotificationEventType, NotificationChannel | APP_SPEAMCORE_VIEW_CONTACT, SPEAMBOX, NOTIFICATION_EVENT_TYPE, NOTIFICATION_CHANNEL |
Schritt-für-Schritt-Anleitung
- Abonnements (
/notification-subscriptions) → + Neu. - Empfaenger wählen — entweder
contactIdoderspeamboxId(oder beides, je nach Subscription-Logik). - Event-Typ wählen.
- Optional Event-Typ-Option (z. B. „Status-Wechsel auf gesperrt").
- Kanal wählen.
- Status auf
active— Subscription ist aktiv.
Toolbar (Detail-Seite)
Schlanke Toolbar oben rechts:
| Icon | Aktion (aria-label) | CASL | Wirkung |
|---|---|---|---|
| ← | Zurückgehen | — | Zurück zur Liste. |
| 🏠 | Zur Startseite gehen | — | Springt auf das Dashboard / /. |
| ⏮/◀/▶/⏭ | Pagination | — | Navigation durch die gefilterte Liste — Massen-Bearbeitung ohne Liste-Sprung. |
Globale Floating-Drawer (links)
Wie auf jeder Detail-Seite verfuegbar — siehe Floating-Quickbar:
- KAL. (Mini-Kalender)
- ZEIT (Persoenliche Wochen-Arbeitszeit)
- ARBEIT (Eigene bevorstehende Aufträge)
Felder und Eingaben
| Feldname | Pflicht | Datentyp | Wirkung beim Ausfuellen | Voraussetzung |
|---|---|---|---|---|
contactId | nein | UUID | Empfaenger-Kontakt. Bei aktiver Subscription wird dieser Kontakt benachrichtigt. | view:Contact. |
speamboxId | nein | UUID | Quell-Box. Wenn gesetzt, gilt die Subscription nur für Events dieser Box. | view:Speambox. |
notificationEventTypeId | nein | UUID | Event-Typ (z. B. „Störung", „Wartung faellig"). Aktualisiert die Auswahl der eventTypeOptions. | view:NotificationEventType. |
notificationEventTypeOptionId | nein | UUID | Praezisierung des Events (z. B. nur „Störung Sirene"). | view:NotificationEventTypeOption. |
notificationChannelId | nein | UUID | Kanal, über den die Nachricht geht. | view:NotificationChannel. |
status | nein | active/inactive | active registriert den Listener im EventBus. inactive pausiert. | — |
subscriberName | — | String (read-only) | Snapshot des Empfaenger-Namens („Vorname Nachname") zum Anlege-Zeitpunkt. Erspart der Admin-Liste den Join auf den Kontakt — wird automatisch gesetzt. | — |
CRUD-Pattern (Standard)
Diese Sub-Route folgt dem Standard-CRUD-Pattern:
- + Neu öffnet ein Modal mit Eingabemaske oder erstellt direkt einen leeren Datensatz und navigiert auf den Detail.
- Detail-Seite verwendet Auto-Save: jede Änderung schreibt sofort via
PATCHin das BE. - Löschen ist Soft-Delete (paranoid) — Datensaetze sind in der Datenbank weiter vorhanden, aber gefiltert.
Spezielles Verhalten dieser Sub-Route ist im jeweiligen Notification-Cluster dokumentiert: siehe Notification-System Konzept.
Persönliche Benachrichtigungs-Einstellungen (seit Juni 2026)
Unabhängig von den Mandanten-Subscriptions kann jeder Mitarbeiter seine eigenen SpeamNotification-Präferenzen festlegen — über das Persönliche-Einstellungen-Modal (in der Oberfläche oben rechts, kein eigener Menüpunkt/Route). Gespeichert wird je Ereignis-Typ am Mitarbeiter (notificationPrefs):
| Kanal | Bedeutung |
|---|---|
Intern (internal) | Anzeige im SpeamCore-Benachrichtigungs-Center. |
Browser (browser) | Browser-Push-Benachrichtigung (Web-Notification). |
App (nativeApp) | Push in der nativen App. |
Zusätzlich gibt es „Browser-Benachrichtigungen verwalten": Hat der Browser die Berechtigung blockiert, zeigt das Modal das an und bietet ein erneutes Anfragen/Prüfen (re-check). Live-Benachrichtigungen erscheinen u. a. bei neuer Mail und neuer Chat-Nachricht.
Wiederverwendbare Konzepte
Verknuepfungen zu anderen Modulen
- Kontakte —
contactId. - SpeamBox —
speamboxId. - NotificationEventType — Event-Typ-Stammdaten.
- NotificationChannel — gewaehlter Kanal.
- NotificationLog — Logs werden bei jedem Subscription-Match erzeugt.
Häufige Fehler und Lösungen
| Fehler | Lösung |
|---|---|
| Empfaenger bekommt keine Nachricht | Subscription inactive, oder Kanal inactive, oder Event-Typ ueberhaupt nicht gefeuert. |
| Mehrfach-Versand | Mehrere Subscriptions matchen — prüfen und ggf. konsolidieren. Hinweis: Gegen doppelten Versand desselben Events über mehrere Server-Instanzen schützt seit Mai 2026 ein deterministischer dedupKey am Notification-Event (nur eine Instanz schreibt + versendet das Event). |
| Kanal-/Event-Mismatch | notificationEventTypeOptionId muss zu notificationEventTypeId passen. |
API/Schnittstellen
| Methode | Endpoint | Zweck | CASL |
|---|---|---|---|
GET | /api/notification-subscriptions | Liste | view NotificationSubscription |
POST | /api/notification-subscriptions | Anlegen | create NotificationSubscription |
PATCH | /api/notification-subscriptions/:id | Ändern | update NotificationSubscription |
DELETE | /api/notification-subscriptions/:id | Soft-Delete | delete NotificationSubscription |
Versionshinweise
- 2026-06-08: Abschnitt „Persönliche Benachrichtigungs-Einstellungen" ergänzt — per-Mitarbeiter
notificationPrefs(intern/Browser/App je Event) über das Persönliche-Einstellungen-Modal, inkl. „Browser-Benachrichtigungen verwalten" + Live-Notifications (neue Mail/Chat). Verifiziert anPersonalSettingsModal.tsx,notificationPrefs.ts,employee.model.ts. - 2026-04-29: Initiale Veroeffentlichung.