# Legacy Zu SaaS Umsetzungsfahrplan

Diese Datei verdichtet die Review des Funktionskatalogs zu einem
umsetzungsorientierten Fahrplan. Ziel ist es, nur solche Themen parallel
anzugehen, die bereits fachlich und technisch sauber geschnitten sind.

## Review Ergebnis

Der Katalog in `docs/legacy-feature-catalog.md` ist als Planungsgrundlage gut,
aber noch nicht komplett implementierungsreif. Mehrere Themen sind im
`saas-app`-Geruest bereits vorbereitet, allerdings oft nur als Datenmodell oder
Demo-Service. Vor einer breiten Parallelumsetzung muessen deshalb zuerst einige
Architektur- und Fachentscheidungen festgezogen werden.

## Harte Blocker Vor Breiter Umsetzung

### 1. Identity-Strategie

Offen:
- OIDC-first mit ADFS als OIDC-Provider
- oder direkter AD-/LDAP-Abgleich

Warum blocker:
- Das aktuelle SaaS-Geruest ist OIDC-orientiert.
- Der Katalog nennt AD und ADFS, beschreibt aber die Zielarchitektur nicht
  praezise genug.

Benötigte Entscheidung:
- [X] Zielpfad fuer Anmeldung und Benutzerabgleich festlegen

Der Verantwortliche für die jeweilige Kaffeeliste sollt auswählen könne, ob per ADFS oder LDAP Anbindung oder Azure AD Abfrage eingerichtet werden kann.

### 2. Rollenmatrix

Offen:
- Welche Rollen gibt es ausser `platform_admin`, `tenant_admin`, `member`?
- Braucht es z. B. `finance_admin`, `support_contact`, `survey_manager`?

Warum blocker:
- Zahlungsfreigaben, Kommunikationswege und Survey-Rechte haengen direkt von
  Rollen ab.

Benötigte Entscheidung:
- [X] Rollenmodell und Rechte pro Rolle festlegen

Ja es sollte Rollen und Rechte pro Rolle geben. Tenant Admin soll immer alle Recht haben


### 3. Zahlungsmodell

Offen:
- Pro Tenant aktivierbare Zahlungsarten
- Bankdaten
- PayPal-Empfaenger
- Catch-all-Mailbox und Zahlungsabgleich

Warum blocker:
- Das aktuelle `payment_entries`-Modell ist fuer einfache Buchungen gut, aber
  noch nicht fuer automatischen Abgleich oder Mailbox-Importe.

Benötigte Entscheidung:
- [Ja umsetzen] Zahlungsarten pro Tenant definieren
- [Ja umsetzen] Reconciliation-Modell definieren
- [Ja umsetzen] Mailbox-Import als eigenes Folgepaket abgrenzen



### 4. Kommunikationsmodell

Offen:
- Soll eine Anfrage nur per Mail weitergeleitet werden?
- Oder als Vorgang im System bestehen bleiben?
- Wer ist die zentrale Administration fachlich genau?

Warum blocker:
- Aktuell existiert nur `support_email`, aber kein Vorgangs- oder Routingmodell.

Benötigte Entscheidung:
- [Ja] Support-Request-Workflow definieren

Die Anfragen information soll an den Verantwortlichen der Anfragen bzw. den Tenant Admin gehen. 
Die Zentrale Administration ist die Verwaltung aller Tenant

### 5. Survey-Modell

Offen:
- Wer darf Surveys anlegen?
- Wie werden Antwortoptionen modelliert?
- Wann sind Ergebnisse fuer Benutzer sichtbar?
- Live-Ansicht oder freigegebener Snapshot?

Warum blocker:
- Das Grundschema existiert, aber Freigabe, Multiple Choice und Auswertung sind
  noch nicht ausreichend modelliert.

Benötigte Entscheidung:
- [ ] Survey-MVP fachlich festziehen

Ermöglich eine Standardgerüst für Umfragen. Die Umfragen sollten von der jeweiligen Rolle oder dem Tenant Administrator vollständig verwaltet werden können.

### 6. Audit Und Storno

Offen:
- Darf weiterhin direkt geloescht werden?
- Oder braucht es kuenftig Storno, Historie und Freigaben?

Warum blocker:
- Legacy arbeitet vielfach mit direkter Loeschung; das ist fuer SaaS und
  Nachvollziehbarkeit meist zu schwach.

Benötigte Entscheidung:
- [X] Korrekturmodell fuer Buchungen definieren
Nein es sollte nicht gelöscht werden können es soll Storne und Historie geben.

## Bereits Tragfaehige Grundlagen Im SaaS-Geruest

Vorhanden:
- Mandantenmodell
- tenantbezogene Einstellungen
- OIDC-Provider- und Identity-Tabellen
- Rollen- und Tenant-User-Grundmodell
- Ledger-, Payment-, Content-, Survey-, Import- und Export-Tabellen
- Feature-Gating fuer mehrere Module

Einordnung:
- Das Geruest ist gut genug, um fokussierte MVPs umzusetzen.
- Es ist nicht gut genug, um alle Themen parallel ohne weitere
  Fachspezifikation produktiv zu bauen.

## Empfohlene Reihenfolge Fuer Spezialistenpakete

### Paket 1. Identity Baseline

Ziel:
- Zielarchitektur fuer Login und Identitaetsverknuepfung festziehen

Scope:
- OIDC-/ADFS-Entscheid dokumentieren
- Provider-Konfiguration pro Tenant
- Benutzeridentitaeten sauber mappen

Ergebnis:
- Eine stabile Basis fuer alle spaeteren Rollen- und Zugriffsthemen

Status:
- [ ] Noch nicht spezifiziert
- [ ] Danach implementierbar

### Paket 2. Rollen Und Verantwortlichkeiten

Ziel:
- Fachrollen fuer Tenant-Betrieb sauber schneiden

Scope:
- Plattform-Admin
- Tenant-Admin
- Mitglied
- optional Finance, Support, Survey-Manager

Ergebnis:
- Klare Berechtigungsbasis fuer Payments, Support und Surveys

Status:
- [ ] Noch nicht spezifiziert
- [ ] Danach implementierbar

### Paket 3. Content MVP

Ziel:
- Hinweise und FAQ durch Tenant-Admins pflegbar machen

Scope:
- CRUD fuer Hinweise
- CRUD fuer FAQ
- aktiv/inaktiv
- Sortierung
- Sichtbarkeit bis Datum
- optionale Standardvorlage als Startbestand

Ergebnis:
- Erstes direkt nutzbares Fachmodul mit bereits passendem Datenmodell

Status:
- [X] Fachlich fast schnittreif
- [ ] Kann frueh implementiert werden

### Paket 4. Support Requests MVP

Ziel:
- Anfragen Benutzer -> Kaffeelistenverantwortliche
- Anfragen Verantwortliche -> zentrale Administration

Scope:
- `support_requests`
- Richtung
- Kategorie
- Nachricht
- Absender
- Ziel
- Status
- Zeitstempel

Ergebnis:
- Ein nachvollziehbarer Kommunikationsprozess statt nackter Mailweiterleitung

Status:
- [ ] Vorher Workflow-Entscheid noetig
- [ ] Danach implementierbar

### Paket 5. Payment Configuration MVP

Ziel:
- Tenant-spezifische Zahlungsarten und Zahlungsdaten

Scope:
- Bar
- Ueberweisung
- PayPal
- aktivierte Methoden
- Hinweise fuer Benutzer
- tenantbezogene Zahlungsparameter

Ergebnis:
- Saubere Grundlage fuer spaetere Automatisierung

Status:
- [ ] Vorher Fachmodell vervollstaendigen
- [ ] Danach implementierbar

### Paket 6. Ledger Audit Und Korrekturen

Ziel:
- Buchungen sicher korrigieren statt direkt loeschen

Scope:
- Storno statt Hard Delete
- Auditfelder
- Referenzen auf Ursprungseintraege
- Begruendung oder Freigabeoption

Ergebnis:
- Nachvollziehbares Buchungsmodell

Status:
- [ ] Vorher Korrekturregeln definieren
- [ ] Danach implementierbar

### Paket 7. Survey Admin MVP

Ziel:
- Tenant-seitige Survey-Erstellung und Verwaltung

Scope:
- Survey anlegen
- Fragen anlegen
- Aktivierungszeitraum
- Ergebnisfreigabe
- Auswertung fuer Tenant-Admins

Ergebnis:
- Nutzbares Survey-Modul fuer den operativen Betrieb

Status:
- [ ] Vorher Antwortoptionen und Freigabemodell ergaenzen
- [ ] Danach implementierbar

### Paket 8. Survey Publishing Fuer Benutzer

Ziel:
- Benutzer duerfen freigegebene Ergebnisse sehen

Scope:
- Freigabeflag
- Benutzeransicht
- Aggregationen
- optionale Snapshot-Logik

Ergebnis:
- Kontrollierte Transparenz statt unklarer Sichtbarkeit

Status:
- [ ] Abhaengig von Paket 7

### Paket 9. Payment Reconciliation

Ziel:
- Zahlungen aus externen Quellen belastbar abgleichen

Scope:
- Status
- externe Referenz
- Quelle
- Matching
- manuelle Klaerung
- Audit

Ergebnis:
- Technische Basis fuer Import- und Mailbox-Automatisierung

Status:
- [ ] Abhaengig von Paket 5

### Paket 10. Catch-All Mailbox Integration

Ziel:
- Zahlungsbenachrichtigungen automatisiert einlesen und zuordnen

Scope:
- Eingangskanal
- Parser
- Sicherheitsregeln
- Matching-Regeln
- Klaerungsfaelle

Ergebnis:
- Eigenstaendige Integrationsstrecke, nicht Teil eines kleinen MVPs

Status:
- [ ] Abhaengig von Paket 9

## Was Jetzt Schon Sicher Parallelisierbar Ist

Diese Themen koennen nach kurzer Feinspezifikation gut durch getrennte
Spezialisten umgesetzt werden:

- Content-MVP
- Rollenmatrix und Rechtekonzept
- Tenant Payment Configuration
- Support-Requests Datenmodell
- Survey-Admin-Konzept

Diese Themen sollten noch nicht in Produktcode parallel umgesetzt werden:

- Catch-all-Mailbox fuer PayPal
- finale Identity-Integration ohne Architekturentscheid
- Survey-Publishing fuer Benutzer ohne Freigabemodell
- Audit-/Storno-Implementierung ohne fachliche Korrekturregeln

## Konkrete Naechste Entscheidungsliste

- [ ] OIDC mit ADFS als Zielpfad bestaetigen oder AD-/LDAP-Abgleich bevorzugen
- [ ] Rollenmatrix festlegen
- [ ] Support Requests als Mailweiterleitung oder Vorgangssystem definieren
- [ ] FAQ/Mailtexte als Standardvorlage mit Tenant-Override bestaetigen
- [ ] Survey-Freigabemodell fuer Benutzer festlegen
- [ ] Storno/Audit statt direkter Loeschung bestaetigen
- [ ] Catch-all-Mailbox ausdruecklich als spaeteres Integrationspaket bestaetigen

## Empfehlung

Wenn du sofort in Umsetzung gehen willst, ist die sauberste Reihenfolge:

1. Content-MVP
2. Rollenmatrix
3. Payment Configuration MVP
4. Support Requests MVP
5. Survey Admin MVP

Erst danach sollten wir Payment-Reconciliation, Mailbox-Import und komplexere
Identity-Integrationen parallelisieren.
