Benachrichtigungs-Log

Zweck

Das Benachrichtigungs-Log (NotificationLog) ist der Audit-Trail aller Benachrichtigungen, die SpeamCore versendet — über E-Mail, SMS, Push, Slack oder andere Kanäle. Pro Eintrag sehen Sie Zeitpunkt, Empfaenger, Kanal, verwendete Vorlage, Status (sent/failed/pending) und ggf. Fehlermeldung. Das Log ist read-only — eine Retry-Aktion erlaubt, fehlgeschlagene Sendungen nochmal anzustossen.

Voraussetzungen

- Berechtigung `view:NotificationLog`. Für Retry zusaetzlich `update:NotificationLog`.

Berechtigungen (CASL)

Action	Subject	Keycloak-Rolle
view	FE_NotificationLog, NotificationLog	—
update	NotificationLog (Retry)	APP_SPEAMCORE_UPDATE_NOTIFICATION_LOG (RETRY)`
delete	NotificationLog	APP_SPEAMCORE_DELETE_NOTIFICATION_LOG

Geschwister-Routen (Notification-Cluster)

Notifications sind als Cluster organisiert — für Konfiguration nutzen Sie weitere Routen:

Pfad	Zweck
/notification-event-types	Event-Definitionen (z. B. „Beleg überfällig", „Auftrag fertig").
/notification-channels	Kanäle (E-Mail, SMS, Push, Slack-Webhook).
/notification-subscriptions	Wer empfaengt welches Event über welchen Kanal?
/notification-templates	Wiederverwendbare Inhaltsvorlagen (Sprachversionen).
/notification-events	Event-Stream — Quelle der einzelnen Logs.
/notification-logs	Diese Seite — Audit-Log der versendeten Notifications.

Schritt-für-Schritt-Anleitung

Log einsehen

1. Benachrichtigungs-Log (/notification-logs) → Liste mit Filter nach Status, Event-Typ, Datum.
2. Klick auf Zeile → Detail-Seite mit Empfaenger, Kanal, Vorlage und ggf. Fehlermeldung.

Fehlgeschlagene Sendung erneut anstossen

1. Auf der Detail-Seite eines Logs mit status = failed: Retry klicken.
2. POST /api/notification-logs/:id/retry startet den Versand neu (gleicher Kanal, gleicher Empfaenger, gleiches Template).

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

Button: „Retry"

Detailseite. Sichtbar nur bei status = failed. Erfordert update:NotificationLog.

Felder und Eingaben

Alle Felder sind read-only — das Log dokumentiert nur. Ausnahme: Retry-Aktion.

Feldname	Datentyp	Wirkung	Voraussetzung
notificationEventId	UUID	Verknuepfung zum Quell-Event.	view:NotificationEvent.
notificationEventType	UUID	Klassifizierung des Events.	view:NotificationEventType.
notificationChannelId	UUID	Kanal (E-Mail, SMS, ...).	view:NotificationChannel.
recipient	String	E-Mail, Telefonnummer oder anderer Identifier.	—
status	sent/failed/pending	Versand-Status. pending ist transient (Job-Queue).	—
sentAt	Datetime	Zeitpunkt des erfolgreichen Versands.	—
failureReason	TEXT	Fehlermeldung bei status = failed.	—

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

• Berechtigungen verstehen (CASL)

Verknuepfungen zu anderen Modulen

• Belege — Beleg-Faelligkeits-Events erzeugen Notifications.
• Aufträge — Status-Wechsel triggert Notifications.
• Compliance — Compliance-Prüfungen senden Warnmeldungen.

Häufige Fehler und Lösungen

Fehler	Lösung
Notification-Versand schlaegt fehl	failureReason prüfen — typisch: SMTP-Konfig, ungueltige Empfaenger-Adresse, fehlende Permissions im Channel. Nach Korrektur Retry klicken.
Notification kommt mehrfach an	NotificationSubscription prüfen — gleicher Empfaenger via mehreren Kanälen oder Subscriptions.
Notification fehlt komplett	Prüfen, ob ein passender NotificationEventType aktiv ist und der Empfaenger eine NotificationSubscription hat.

API/Schnittstellen

Methode	Endpoint	Zweck	CASL
GET	/api/notification-logs	Liste	view NotificationLog
GET	/api/notification-logs/:id	Detail	view NotificationLog
POST	/api/notification-logs/:id/retry	Erneut senden	update NotificationLog
DELETE	/api/notification-logs/:id	Soft-Delete	delete NotificationLog

Versionshinweise

• 2026-04-29: Initiale Veroeffentlichung mit FE-Tiefen-Standard.