Benachrichtigungs-Events

Zweck

Der Event-Stream (NotificationEvent) zeigt alle konkret ausgeloesten Events — z. B. wenn ein Auftrag auf finished wechselt oder eine Störung an einer SpeamBox auftritt. Die Liste ist read-only: Events entstehen automatisch durch Plattform-Aktivität. Ein Test-Dispatch-Modal erlaubt Administratoren, ein Event manuell zu erzeugen — z. B. zur Validierung einer Subscription-Konfiguration.

Voraussetzungen

- Berechtigung `view:NotificationEvent`. - Für Test-Dispatch zusaetzlich `create:NotificationEvent`.

Berechtigungen (CASL)

Action	Subject	Wirkung	Keycloak-Rolle
view	FE_NotificationEvent, NotificationEvent	Stream lesbar	—
create	NotificationEvent	Test-Dispatch	APP_SPEAMCORE_CREATE_NOTIFICATION_EVENT

Schritt-für-Schritt-Anleitung

Stream lesen

1. Events (/notification-events).
2. Filter nach Status (pending, processed, failed).
3. Tabellen-Spalten: Event-Typ, Status, Erzeugt am, ggf. SpeamBox.

Test-Event ausloesen

1. Test-Dispatch klicken — Modal öffnet sich.
2. Event-Typ, Channel und ggf. Empfaenger wählen.
3. Senden — POST /api/notification-events erzeugt das Event und es laeuft durch das Subscription-Matching.

Test-Dispatch kann **echte Benachrichtigungen** ausloesen — prüfen Sie vor dem Klick, ob aktive Subscriptions existieren, die den Event aufnehmen.

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)

UI-Elemente

Modal: Test-Dispatch

Eingabefelder für Event-Typ, ggf. SpeamBox, Test-Payload. Loest beim Senden ein echtes Event aus, das alle aktiven Subscriptions durchlaeuft.

Felder und Eingaben

Read-only — keine direkten Eingaben pro Eintrag.

Feldname	Datentyp	Wirkung	Voraussetzung
notificationEventTypeId	UUID (read-only)	Klassifizierung des Events.	—
speamboxId	UUID (read-only, nullable)	Quell-Box, falls hardware-getriggert.	—
status	pending/processed/failed	Phase der Verarbeitung. Wird vom Backend-Worker getriggert.	—
payload	JSON (read-only)	Daten-Snapshot zum Event-Zeitpunkt.	—
createdAt	DateTime (read-only)	Zeitstempel der Aufnahme.	—

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 PATCH in 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.

Wiederverwendbare Konzepte

• Notification-System
• Berechtigungen verstehen (CASL)

Verknuepfungen zu anderen Modulen

• NotificationEventType — Quelle der Klassifizierung.
• NotificationSubscription — Empfaenger-Routing.
• NotificationLog — Versand-Audit pro Event und Empfaenger.
• SpeamBox — viele hardware-getriggerte Events haben einen speamboxId.

Häufige Fehler und Lösungen

Fehler	Lösung
Status bleibt auf pending	Worker laeuft nicht oder ist gestaut.
Event existiert, aber kein Log	Keine aktive Subscription matcht.
Test-Dispatch erzeugt Spam	Vor dem Klick Subscriptions prüfen — ggf. testweise auf inactive setzen.

API/Schnittstellen

Methode	Endpoint	Zweck	CASL
GET	/api/notification-events	Stream lesen	view NotificationEvent
POST	/api/notification-events	Test-Dispatch	create NotificationEvent

Versionshinweise

• 2026-04-29: Initiale Veroeffentlichung.