DB-Schema-Detailprüfung UC06 – Kunden einladen & Portal

Stand: 01.08.2026 14:55 Branch: docs/einheitliche-kopfbereiche Status: Abgeschlossen; Gegen vorhandene UC06-Spezifikation und Prisma-Zielschema v3 konzeptionell geprüft

Datum, Uhrzeit	Version	Änderung	Autor
01.08.2026 14:55	1.0	Kopfbereich vereinheitlicht	David Mittig
01.08.2026 11:12	1.0	Kopfbereich ergänzt	David Mittig

---

1. Prüfgrundlage

Geprüft wurde gegen:

• docs/developer/uc06/uc06-spezifikation.md,
• backend/prisma/schema.prisma v3,
• docs/developer/uc00/db-schema-zielbild-uc-matrix.md,
• docs/developer/db-schema.md v6,
• docs/management/roadmap.md.

Korrekturhinweis:

Die frühere Fassung dieser Detailprüfung enthielt die falsche Aussage, dass keine eigene UC06-Spezifikation gefunden wurde. Die Spezifikation existiert und wurde in dieser Nachprüfung berücksichtigt.

2. Fachlicher UC-Zweck aus der Spezifikation

UC06 ermöglicht es einer Tauchschule, Kunden zum Kundenportal einzuladen und deren Zugang zu aktivieren.

Das Kundenportal gibt dem Kunden in V1 einen begrenzten, sicheren Self-Service-Zugang auf eigene Stammdaten, eigenes Equipment, eigene Fristenhinweise und spätere Portal-Hinweise aus UC07.

3. Spezifikationsanforderungen gegen Prisma-Zielschema

Anforderung UC06	Prisma-Zielschema v3	Bewertung
Kunde einladen	InvitationToken, InvitationTokenType.customer_invite	abbildbar
Portalzugang aktivieren	Customer.userId, User.role = kunde	abbildbar
Kunde sieht eigene Daten	Customer, User	abbildbar, Backend-Berechtigung offen
Kunde sieht eigenes Equipment	Equipment.customerId	abbildbar
Kunde sieht eigene Fristen	über Equipment, CylinderDetails, RegulatorDetails	abbildbar
Portalaktivität protokollieren	CustomerActivityLog, AuthLog	abbildbar
Einladung erneut senden / widerrufen	InvitationToken.status, revokedAt, expiresAt	abbildbar
Stammdatenänderung anfragen	keine change_requests in V1	bewusst offen / V2
Einladungsstatus not_invited, invitation_draft, accepted, blocked	kein eigener Portalstatus	teilweise offen
Kunde-Bezug im Token	indirekt über Customer.userId nach Annahme, aber kein customerId am Token	teilweise offen

4. Feld-für-Feld-Bewertung

4.1 Customer und User

Abbildbar über:

• Customer.userId,
• Customer.email,
• User.email,
• User.role = kunde,
• User.status,
• User.tenantId.

Bewertung:

• Der Portalzugang ist konzeptionell abbildbar.
• Die Spezifikation fordert einen eindeutigen Kundenbezug zum Token. Im Prisma-Zielschema ist dieser vor der Annahme nur indirekt über die E-Mail abbildbar, nicht über InvitationToken.customerId.

4.2 InvitationToken

Abbildbar über:

• tokenType = customer_invite,
• invitedEmail,
• invitedRole = kunde,
• status,
• expiresAt,
• usedAt,
• revokedAt.

Bewertung:

• Für einfache Kundenportal-Einladung ausreichend.
• Nicht vollständig für alle Spezifikationsstatuswerte, weil kein eigenes Portal-/Invitation-Statusmodell je Customer existiert.

4.3 Portalaktivität

Abbildbar über:

• CustomerActivityLog,
• AuthLog,
• AccessLog.

Bewertung:

• Portal-Aktivität ist grundsätzlich protokollierbar.

5. Relevante Abweichungen / offene Designpunkte

Punkt	Bewertung	Empfehlung
kein customerId in InvitationToken	relevante Lücke für eindeutigen Vorannahme-Bezug	Feld ergänzen oder Prozess über Customer.email verbindlich definieren
kein eigenes Portalstatusfeld am Customer	Spezifikation nennt mehrere Portalstatuswerte	portalStatus prüfen oder Status aus User/Token ableiten
keine change_requests	V1-light vorbereitet, aber nicht modelliert	bewusst V2 oder Minimalmodell entscheiden
Kundenadressfelder fehlen	für V1-read-only nicht zwingend	bei Stammdatenanzeige prüfen
Multi-Tenant-Kundenportal	bewusst V2	korrekt abgegrenzt

6. Ergebnis

UC06 ist im Prisma-Zielschema v3 für einen einfachen V1-Kundenportalzugang konzeptionell abbildbar.

UC06 ist nicht vollständig gemäss Spezifikation abgebildet, wenn die Spezifikationsanforderung „Token muss eindeutig einem Kunden zugeordnet sein" streng als eigenes customerId am Token verstanden wird.

Korrekte Statusformulierung:

UC06 ist gegen die vorhandene Spezifikation geprüft. Das Prisma-Zielschema v3 deckt den V1-Kern für Kundeneinladung und read-only Portal konzeptionell ab; offene Designpunkte bestehen bei direktem Token-Kundenbezug, Portalstatus und Change-Requests.

7. Offene Nacharbeit

• [ ] Entscheidung: InvitationToken.customerId ergänzen oder Kundenbezug über E-Mail/Prozess definieren.
• [ ] Entscheidung: Customer.portalStatus ergänzen oder Portalstatus ableiten.
• [ ] Entscheidung: V1-light für Änderungsanfragen modellieren oder bewusst V2.
• [ ] Backend-Berechtigungsmodell für Kunde sieht nur eigene Daten definieren.
• [ ] Technische Prisma-Validierung bleibt offen.