diff --git a/docs/legacy-feature-catalog.md b/docs/legacy-feature-catalog.md index 326ab49..d5abcfe 100644 --- a/docs/legacy-feature-catalog.md +++ b/docs/legacy-feature-catalog.md @@ -13,6 +13,9 @@ Umsetzungspakete genutzt werden kann. - Die Inhalte stammen aus einer Codeanalyse der Legacy-Seiten und muessen bei Bedarf um fachliche Regeln aus FAQ, E-Mails und Betriebswissen ergaenzt werden. +- Fuer Entwicklungsarbeit reicht dieser Katalog allein nicht aus; die + ergaenzenden Leitplanken und Mindestanforderungen in diesem Dokument sind vor + paralleler Umsetzung mitzupflegen. ## Empfohlene Planungsmodule @@ -58,8 +61,8 @@ Ziel fuer SaaS: - [ ] Entfaellt Manuelle Ergaenzungen: -- -- +- +- ### 2. Operative Buchung und Kassenfuehrung @@ -96,8 +99,8 @@ Ziel fuer SaaS: - [ ] Entfaellt Manuelle Ergaenzungen: -- -- +- +- ### 3. Uebersichten, Reporting und Export @@ -128,8 +131,8 @@ Ziel fuer SaaS: - [ ] Entfaellt Manuelle Ergaenzungen: -- -- +- +- ### 4. Mitglieder, Rollen und Berechtigungen @@ -161,8 +164,9 @@ Ziel fuer SaaS: - [ ] Entfaellt Manuelle Ergaenzungen: -- die Authentifizierung an einem AD und ADFS sollen hinzugefügt werden. -- +- Die Authentifizierung an AD und ADFS soll hinzugefuegt werden. +- Eine Azure-AD-Variante ist ebenfalls als moegliche Tenant-Integration zu + pruefen. ### 5. Kommunikation, Hinweise und Benachrichtigungen @@ -196,8 +200,10 @@ Ziel fuer SaaS: - [ ] Entfaellt Manuelle Ergaenzungen: -- Es solle die möglichkeit geben auch Anfragen von dem Benutzern an den Verantwortlichen der Kaffeeliste des jeweiligen Kunden zusenden. -- Es soll die möglichkeit geben das der Verwortliche der Kaffeeliste auch Anfragen an die zentrale Administration stellen kann. +- Es soll die Moeglichkeit geben, dass Benutzer Anfragen an die + Verantwortlichen der Kaffeeliste des jeweiligen Kunden senden koennen. +- Es soll die Moeglichkeit geben, dass Verantwortliche der Kaffeeliste Anfragen + an die zentrale Administration stellen koennen. ### 6. Feedback und Umfragen @@ -225,8 +231,10 @@ Ziel fuer SaaS: - [ ] Entfaellt Manuelle Ergaenzungen: -- Es soll möglich sein, das die Verantwortlichen der Kaffeeliste Umfrage einrichten können. Die Verantwortlichen der Kaffeeliste sollten die Umfrange vollumfänglich verwalten und auswerten können. -- +- Es soll moeglich sein, dass Verantwortliche der Kaffeeliste Umfragen + einrichten koennen. +- Verantwortliche der Kaffeeliste sollen Umfragen vollumfaenglich verwalten und + auswerten koennen. ### 7. Sonderprozesse und Jahresabschluss @@ -251,8 +259,9 @@ Ziel fuer SaaS: - [ ] Entfaellt Manuelle Ergaenzungen: -- Es sollt die möglichkeit geben eine Jahresbonus z.B. anhand der im Jahr verbrauchten Strichen zu verteilen an die Mitglieder -- +- Es soll die Moeglichkeit geben, einen Jahresbonus oder eine + Sonderausschuettung anhand der im Jahr verbrauchten Striche zu verteilen. +- ## Seiteninventar @@ -281,11 +290,13 @@ Manuelle Ergaenzungen: - [X] Soll die Vorderseiten-/Rueckseitenlogik aus dem Papierprozess erhalten bleiben? - [X] Soll Self-Service-Stricherfassung erhalten bleiben? -- [ ] Soll die Zahlung weiter ueber reine PayPal-Links laufen? -- [X] Brauchen Loeschungen kuenftig Storno- und Audit-Logik? -- [ ] Wer darf Umfrageergebnisse sehen? -- [ ] Ist `mailausgebe.php` fachlich gewollt oder nur Hilfsfunktion? -- [ ] Ist `jahresauswertung.php` ein wiederkehrender Prozess? +- [X] Soll die Zahlung ueber ein konfigurierbares Zahlungsmodul mit mehreren + Zahlarten laufen? +- [X] Brauchen Korrekturen kuenftig Storno- und Loeschregeln? +- [X] Umfrageergebnisse werden nach Freigabe durch Tenant-Verantwortliche oder + Survey-Verantwortliche sichtbar. +- [X] `mailausgebe.php` spielt fuer die neue Webseite keine Rolle. +- [X] Jahresauswertungen sollen als bedarfsorientierter Prozess moeglich sein. - [ ] Welche Fachregeln aus FAQ und Mailtexten muessen als echte Anforderungen uebernommen werden? - [ ] Welche Zusatzfelder braucht das kuenftige Benutzerprofil, z. B. @@ -294,10 +305,181 @@ Manuelle Ergaenzungen: ## Notizen -- Die Zahlung soll der Verantwortliche der Kaffeeliste einstellen können. Bar, Überweisung und Paypal sollen auswählbar sein. Bei Paypal können die E-Mails von Paypal an ein bestimmtes Postfach gesendet werden. Dieses wird von der Seite regelmäßig aus gelesen werden. Dabei soll ein catch-all Postfach gearbeitet werden. Die Empfängeradresse legt die jeweilige Kaffeeliste fest. Der Empfänger ist der Name. -- Die Umfrageergebnisse sollten nach Freigabe des Verantwortlichen auch die Benutzer sehen können. -- mailausgabe.php ist vermutlich nur eine Hilfsfunktion. -- jahresauswertung.php soll im Rahmen der gesamtdarstellung und die Jahes sonderausschüttung benötigt wurden sein. -- die FAQ und Mailtexte müssen durch die Verantwortlichen der Kaffeeliste angepasst werden können, es soll aber eine StandardVorlage geben -- Welche Feld noch benötigt, muss ermittelt werden. -- \ No newline at end of file +- Die Zahlung soll der Verantwortliche der Kaffeeliste einstellen koennen. Bar, + Ueberweisung und PayPal sollen auswaehlbar sein. +- Bei PayPal koennen Benachrichtigungen an ein tenantbezogenes Postfach gesendet + werden. Ein Catch-all-Postfach fuer automatisierte Auswertung ist als spaeteres + Integrationspaket vorgesehen. +- Die Umfrageergebnisse sollen nach Freigabe des Verantwortlichen auch die + Benutzer sehen koennen. +- `mailausgebe.php` wird fuer die neue Webseite nicht uebernommen. +- Jahresauswertungen sollen bei Bedarf durch Verantwortliche ausgeloest werden + koennen, inklusive moeglicher fixer oder flexibler Boni. +- FAQ und Mailtexte muessen durch die Verantwortlichen der Kaffeeliste angepasst + werden koennen; zusaetzlich soll es eine Standardvorlage geben. +- Welche weiteren Profilfelder benoetigt werden, muss tenantweit noch ermittelt + werden. + +## Ergaenzte Leitplanken Fuer Das SaaS-Zielbild + +Diese Leitplanken verdichten die bisher bekannten Antworten aus Katalog, +Roadmap und Review. Sie ersetzen noch keine Detailkonzepte, schaffen aber eine +stabilere Basis fuer die Fachspezifikation. + +### Bereits Vorlaeufig Geklaert + +- Self-Service-Stricheintrag soll erhalten bleiben, aber tenantbezogen + aktivierbar sein. +- Einzahlungen sollen stornierbar sein; Stricheintraege sollen durch + Verantwortliche loeschbar sein. +- Tenant-Admins sollen ihre Inhalte fuer Hinweise, FAQ, Umfragen und + Zahlungsarten selbst pflegen koennen. +- Zahlungsarten sollen pro Tenant konfigurierbar sein: mindestens Bar, + Ueberweisung und PayPal. +- Umfrageergebnisse sollen fuer Benutzer erst nach expliziter Freigabe sichtbar + werden. +- FAQ- und Kommunikationstexte sollen als Standardvorlagen verfuegbar sein und + tenantseitig ueberschrieben werden koennen. +- Supportanfragen sollen je nach Richtung an Tenant-Verantwortliche oder + Plattform-Administration geroutet werden. +- Anmeldung soll immer lokal im System moeglich sein und zusaetzlich per + ADFS/OIDC erfolgen koennen. +- `mailausgebe.php` wird nicht als Produktfunktion fuer die neue Webseite + uebernommen. + +### Noch Fachlich Zu Praezisieren + +- Wie Erstlogin, Fallback und Dubletten bei lokaler Anmeldung plus ADFS/OIDC + behandelt werden. +- Welche Spezialrollen neben `tenant_admin` und `member` benoetigt werden und + welche Rechte diese konkret haben. +- Ob Zahlungsabgleiche per PayPal-Mailbox Teil des MVPs sind oder ein spaeteres + Integrationspaket bilden. +- Wie Jahresauswertungen und moegliche Bonus-/Sonderausschuettungen fachlich + parametrisiert werden. +- Welche zusaetzlichen Profilfelder kuenftig tenantweit oder pro Benutzer + gepflegt werden muessen. + +### Empfohlene Detailentscheidungen + +- Identity: lokale Anmeldung immer aktiv, ADFS/OIDC als einzige zusaetzliche + externe Anmeldung, E-Mail-Mapping als Standard, Admin-Klaerfall bei + Dubletten. +- Payment: Reconciliation und Mailbox-Abgleich nicht im MVP, aber mit + vorbereiteten Statusfeldern fuer spaetere Erweiterung. +- Surveys: Mitglieder sehen freigegebene Snapshots statt Live-Daten. +- Jahresauswertung: bedarfsorientierter Admin-Prozess mit Vorschau, Freigabe + und parametrisierbarer Bonuslogik. +- Profilfelder: tenantweit konfigurierbare Zusatzfelder; `paypalname` ist + Startkandidat fuer Matching. +- Schutzmechanismen: Vorschau und Testmodus fuer riskante Sammelaktionen im MVP, + Vier-Augen-Freigabe fuer Jahresauswertung, Massenmail, Import und + Sammel-Storno; die Vier-Augen-Freigabe muss tenantweit deaktivierbar sein. + + +## Mindestanforderungen Fuer Entwicklungsreife + +Die folgenden Punkte fehlen in der Legacy-Ableitung noch oder sind nur implizit +enthalten. Sie sollten vor paralleler Umsetzung je Modul ergaenzt werden. + +### Funktionale Mindesttiefe + +- Pro Modul eine kurze Fachspezifikation mit Ausloeser, Vorbedingungen, + Nachbedingungen und Fehlerfaellen. +- Pro Modul Akzeptanzkriterien fuer den MVP. +- Pro Workflow ein Statusmodell, mindestens fuer Support Requests, Surveys, + Zahlungsabgleich und Buchungskorrekturen. +- Pro Integrationspunkt eine Beschreibung des Eingangsformats, der + Fehlerbehandlung und der manuellen Klaerfaelle. + +### Rollen Und Rechte + +- Rechte-Matrix pro Rolle und Aktion, z. B. lesen, anlegen, freigeben, + korrigieren, exportieren, versenden. +- Klarstellung, welche Rechte `tenant_admin` immer besitzt und welche + Spezialrollen delegierbar sind. +- Tenant-Grenzen fuer Zugriffe, Exporte und Supportvorgaenge. +- Trennung zwischen Authentifizierung, Autorisierung und Benutzerabgleich. + +### Daten Und Historie + +- Felddefinitionen fuer Zahlungsdaten, Benutzerprofile, Support Requests, + Surveys und Exportparameter. +- Regeln fuer Storno, Referenzen auf Ursprungseintraege und unveraenderliche + Audit-Historie. +- Aufbewahrung, Archivierung und Sichtbarkeit historischer Daten. +- Dubletten- und Matching-Regeln fuer CSV-Importe und Mailbox-Abgleiche. + +### Betrieb, Sicherheit Und Compliance + +- Datenschutz- und Berechtigungskonzept fuer Mailadressen, Exporte und + Kontostandskommunikation. +- Logging, Monitoring und Benachrichtigung bei fehlerhaften Importen, + Massenaktionen und Integrationsfehlern. +- Backup-/Restore-Anforderungen fuer tenantkritische Daten. +- Schutzmechanismen fuer risikoreiche Aktionen wie Serienmail, Jahresabschluss + und Sammelbuchungen, z. B. Vorschau, Testmodus, Vier-Augen-Freigabe. + +### Testbarkeit Und Abnahme + +- Mindestabdeckung fuer Unit-, Integrations- und End-to-End-Tests. +- Testdaten und Referenzfaelle fuer typische Tenant-Szenarien. +- Abnahmefaelle fuer Rollen, Storno, Zahlungsabgleich, Supportrouting und + Survey-Freigabe. +- Definition of Done je Paket inklusive Doku, Monitoring und Betriebsfreigabe. + +## Empfohlene Modulspezifikation Vor Umsetzung + +Bevor ein Team ein Paket umsetzt, sollte fuer das jeweilige Modul mindestens +dieser kurze Steckbrief vorliegen: + +| Punkt | Erwartete Aussage | +| --- | --- | +| Ziel | Welches Fachproblem loest das Modul im MVP? | +| Rollen | Wer darf lesen, pflegen, freigeben, exportieren oder korrigieren? | +| Kernworkflow | Welche Schritte durchlaeuft ein Vorgang von Start bis Abschluss? | +| Daten | Welche Stammdaten, Bewegungsdaten und Referenzen werden benoetigt? | +| Fehlerfaelle | Welche Validierungs-, Import- und Berechtigungsfehler gibt es? | +| Historie | Welche Aktionen muessen nachvollziehbar protokolliert werden? | +| Akzeptanz | Woran erkennen Fachseite und Entwicklung, dass der MVP fertig ist? | + +## Entscheidungsbedarf Fuer Die Naechste Runde + +Diese Entscheidungen sind aus heutiger Sicht die wichtigsten, bevor mehrere +Teams parallel in Produktcode arbeiten: + +1. Identity-Zielbild: ein bevorzugter Standardpfad oder tenantweise frei + verfuegbare lokale Anmeldung plus zusaetzliches ADFS/OIDC mit E-Mail-Mapping. +2. Rollenmodell: finale Rollenliste plus Rechte-Matrix mit Admin-Override. +3. Supportmodell: Vorgangssystem mit Status, Routing und Sichtbarkeit. +4. Zahlungs-MVP: nur Konfiguration und manuelle Buchung oder bereits mit + Reconciliation-Vorbereitung. +5. Survey-Freigabe: wer freigibt, welche Ergebnisse sichtbar werden und ob live + oder per Snapshot veroeffentlicht wird. +6. Jahresauswertung: bedarfsorientierter Fachprozess mit welchen Parametern und + Freigaben. + + +### Konkrete Festlegungen Aus Der Review + +- Anmeldung funktioniert immer per lokaler Systemanmeldung und zusaetzlich per + ADFS/OIDC. +- Rollen `finance_admin`, `support_contact` und `survey_manager` sollen als + Spezialrollen vorgesehen werden. +- Supportanfragen sollen in der Anwendung als Vorgang mit Status sichtbar sein; + Empfaenger sind Tenant-Verantwortliche oder Support-Verantwortliche. +- Zahlungsabgleiche per PayPal-Mailbox sind nicht Teil des MVPs. +- Reconciliation wird als Folgepaket geplant, aber im Datenmodell vorbereitet. +- `mailausgebe.php` wird nicht uebernommen, ausser eine andere Produktfunktion + braucht diese Ausgabe technisch intern. +- Zusaetzliche Profilfelder sollen tenantweit definiert werden; ein Kandidat ist + `paypalname` fuer Matching-Zwecke. +- Survey-Freigaben erfolgen durch Tenant-Verantwortliche oder + Survey-Verantwortliche. Diese steuern Freischaltung, Ende und + Veroeffentlichung. +- Fuer Benutzer werden freigegebene Snapshot-Staende veroeffentlicht. +- Es gibt keinen fixen Jahresabschluss; stattdessen soll eine bedarfsorientierte + Jahresauswertung mit fixer oder flexibler Bonusverteilung moeglich sein. +- Vorschau und Testmodus sollen fuer risikoreiche Sammelaktionen Teil des MVPs + sein; Vier-Augen-Freigabe fuer besonders kritische Aktionen folgt ebenfalls + dem Zielbild und muss tenantweit deaktivierbar sein. diff --git a/docs/legacy-implementation-roadmap.md b/docs/legacy-implementation-roadmap.md index 3340821..491b8bd 100644 --- a/docs/legacy-implementation-roadmap.md +++ b/docs/legacy-implementation-roadmap.md @@ -10,107 +10,233 @@ 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. +Architektur-, Fach- und Betriebsentscheidungen festgezogen werden. + +## Zusammenfassung Fuer Die Projektsteuerung + +Aktuell ist die Roadmap als Themenkarte brauchbar, aber noch nicht belastbar +fuer eine breite Parallelisierung mehrerer Entwicklungsteams. + +Belastbar vorbereitet: +- Content-MVP fuer Hinweise und FAQ +- Grundlegende Payment-Konfiguration auf Tenant-Ebene +- Survey-Admin-MVP als fachliches Folgepaket + +Noch nicht belastbar vorbereitet: +- Identity-Strategie und Benutzerabgleich +- Rollen- und Rechte-Matrix +- Audit-/Storno-Modell fuer Buchungen +- Support-Request-Workflow +- Nichtfunktionale Anforderungen, Test- und Abnahmekriterien + +## Stand Der Bisherigen Entscheidungen + +### Vorlaeufig Geklaerte Leitplanken + +- Self-Service-Striche sollen erhalten bleiben und tenantweit schaltbar sein. +- Einzahlungen sollen im Zielsystem stornierbar sein; Stricheintraege sollen + durch Verantwortliche loeschbar bleiben. +- Tenant-Admins sollen Inhalte, Zahlungsarten und Surveys verwalten koennen. +- Zahlungsarten sollen pro Tenant mindestens Bar, Ueberweisung und PayPal + unterstuetzen. +- Survey-Ergebnisse sollen erst nach Freigabe fuer Mitglieder sichtbar werden. +- FAQ- und Kommunikationstexte sollen als Standardvorlage plus Tenant-Override + modelliert werden. +- Supportanfragen sollen zwischen Benutzer, Tenant-Verantwortlichen und + Plattform-Administration routebar sein. + +### Noch Offene Produktentscheidungen + +- Konkrete Rechte-Matrix pro Rolle und Objekt finalisieren. +- Konkrete Parameter und Freigabelogik fuer Jahresauswertungen und Boni. ## Harte Blocker Vor Breiter Umsetzung ### 1. Identity-Strategie +Status: +- [X] Zielbild festgelegt +- [ ] Detailkonzept vor Implementierung spezifizieren + Offen: -- OIDC-first mit ADFS als OIDC-Provider -- oder direkter AD-/LDAP-Abgleich +- lokale DB-Anmeldung im System +- zusaetzliche ADFS-/OIDC-Anmeldung +- E-Mail-basiertes Mapping zwischen externer Identitaet und internem Benutzer Warum blocker: - Das aktuelle SaaS-Geruest ist OIDC-orientiert. -- Der Katalog nennt AD und ADFS, beschreibt aber die Zielarchitektur nicht - praezise genug. +- Login, Tenant-Zuordnung, Benutzerabgleich und Rollenvergabe haengen direkt an + dieser Entscheidung. +- Das Zielbild ist festgelegt, aber das Detailkonzept fuer Fallback, Mapping und + Erstlogin fehlt noch. -Benötigte Entscheidung: -- [X] Zielpfad fuer Anmeldung und Benutzerabgleich festlegen +Mindestinhalt der Entscheidung: +- lokale Anmeldung immer verfuegbar +- ADFS/OIDC als einzige zusaetzliche externe Anmeldung +- Mapping zwischen externer Identitaet und internem Benutzer per E-Mail +- Regeln fuer Erstlogin, Reaktivierung und Dubletten -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. +Empfehlung: +- Lokale Anmeldung bleibt verpflichtend verfuegbar. +- ADFS/OIDC wird als einzige zusaetzliche externe Anmeldung vorgesehen. +- Beim Erstlogin per ADFS/OIDC erfolgt das Mapping primaer ueber E-Mail. +- Bei Dubletten oder unklaren Zuordnungen wird ein Admin-Klaerfall erzeugt. ### 2. Rollenmatrix +Status: +- [~] Rollen grundsaetzlich festgelegt +- [ ] Rechte-Matrix vor Implementierung spezifizieren + Offen: -- Welche Rollen gibt es ausser `platform_admin`, `tenant_admin`, `member`? -- Braucht es z. B. `finance_admin`, `support_contact`, `survey_manager`? +- Welche Rechte gelten pro Rolle und Objekt? Warum blocker: -- Zahlungsfreigaben, Kommunikationswege und Survey-Rechte haengen direkt von - Rollen ab. +- Zahlungsfreigaben, Kommunikation, Surveys, Exporte und Korrekturen haengen + direkt von Berechtigungen ab. +- "Tenant Admin hat alles" reicht nicht als umsetzbare Rechtebeschreibung. -Benötigte Entscheidung: -- [X] Rollenmodell und Rechte pro Rolle festlegen +Mindestinhalt der Entscheidung: +- Rollenliste mit `platform_admin`, `tenant_admin`, `finance_admin`, + `support_contact`, `survey_manager`, `member` +- Rechte-Matrix pro Aktion und Objekt +- Tenant-Grenzen und Admin-Override +- Delegation von Spezialrollen -Ja es sollte Rollen und Rechte pro Rolle geben. Tenant Admin soll immer alle Recht haben +Empfohlene Rechte-Matrix: +| Rolle | Benutzer / Identitaet | Rollenverwaltung | Buchungen / Einzahlungen | Support | Surveys | Content / FAQ | Reporting / Export | +| --- | --- | --- | --- | --- | --- | --- | --- | +| `platform_admin` | global verwalten, Tenant-Identity einrichten | global | global | global | global | global | global | +| `tenant_admin` | tenantweit alles | tenantweit alles | anlegen, bearbeiten, Einzahlungen stornieren, Striche loeschen | Vorgaenge sehen und bearbeiten | anlegen, freigeben, auswerten | pflegen | tenantweit exportieren und auswerten | +| `finance_admin` | Benutzerdaten nur fuer Buchungskontext lesen | nein | Einzahlungen buchen und stornieren, Striche loeschen, Salden korrigieren | lesen | lesen | lesen | Finanz- und Buchungsreports exportieren | +| `support_contact` | Benutzerdaten nur im Supportkontext lesen | nein | nein | Supportvorgaenge sehen, bearbeiten, schliessen | nein | lesen | supportbezogene Auswertungen lesen | +| `survey_manager` | Benutzerdaten nur minimal lesen, falls fuer Surveys noetig | nein | nein | nein | Umfragen anlegen, freigeben, auswerten, veroeffentlichen | lesen | Survey-Reports exportieren | +| `member` | eigenes Profil lesen und pflegen, Login lokal oder via `ADFS/OIDC` | nein | eigene Eintraege sehen, Self-Service nur wenn freigeschaltet | eigene Anfragen stellen und Status sehen | teilnehmen, freigegebene Ergebnisse sehen | lesen | eigene bzw. freigegebene Auswertungen lesen | + +Hinweise: +- `tenant_admin` hat im eigenen Tenant Vollzugriff. +- Spezialrollen erhalten nur die fuer ihr Modul noetigen Rechte. +- `platform_admin` darf tenantuebergreifend administrieren. +- Einzahlungen koennen nur durch Verantwortliche storniert werden. +- Stricheintraege koennen nur durch Verantwortliche geloescht werden. ### 3. Zahlungsmodell -Offen: -- Pro Tenant aktivierbare Zahlungsarten -- Bankdaten -- PayPal-Empfaenger -- Catch-all-Mailbox und Zahlungsabgleich +Status: +- [~] Teilweise geklaert +- [ ] Vor Implementierung zu vervollstaendigen + +Bereits geklaert: +- Zahlungsarten pro Tenant sind gewollt. +- Bar, Ueberweisung und PayPal sollen Teil des MVPs sein. +- Catch-all-Mailbox soll als eigenes Folgepaket abgegrenzt werden. +- Payment-Reconciliation ist nicht Teil des MVPs und folgt als eigenes Paket + nach stabiler manueller Buchung. + +Noch offen: +- Welche Zahlungsdaten pro Tenant gepflegt werden muessen. +- Welche Hinweise und Pflichtfelder pro Zahlungsart sichtbar sind. +- Welche manuellen Klaerfaelle vorgesehen sind. 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 +- Das aktuelle `payment_entries`-Modell reicht fuer einfache Buchungen, aber + nicht fuer belastbaren Abgleich, Fehlerfaelle und spaetere Automatisierung. +Empfehlung: +- Im MVP nur Konfiguration und manuelle Buchung umsetzen. +- Fuer spaetere Reconciliation bereits Statusfelder wie `neu`, `gematcht`, + `pruefen`, `storniert` vorbereiten. +- Mailbox-Import und automatisches Matching bleiben Folgepakete. ### 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? +Status: +- [X] Zielbild fachlich festgelegt +- [ ] Workflow und Statusmodell vor Implementierung spezifizieren + +Bereits geklaert: +- Anfragen sollen an Tenant-Verantwortliche bzw. Tenant-Admins gehen. +- Die Plattform-Administration ist die zentrale Verwaltung aller Tenants. +- Support soll direkt als vollstaendiges Vorgangssystem starten. + +Noch offen: +- Status, Eskalation, Routing und Bearbeitungsregeln. +- Sichtbarkeit fuer Benutzer, Tenant-Admins und Plattform-Admins. 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 +- Aktuell existiert nur `support_email`, aber kein belastbares Workflow- oder + Routingmodell. ### 5. Survey-Modell -Offen: -- Wer darf Surveys anlegen? -- Wie werden Antwortoptionen modelliert? -- Wann sind Ergebnisse fuer Benutzer sichtbar? -- Live-Ansicht oder freigegebener Snapshot? +Status: +- [~] Teilweise geklaert +- [ ] Vor Implementierung zu vervollstaendigen + +Bereits geklaert: +- Tenant-seitige Erstellung und Verwaltung ist gewollt. +- Mitglieder sollen Ergebnisse erst nach Freigabe sehen. +- Fuer Mitglieder werden veroeffentlichte Snapshots empfohlen, keine + Live-Ergebnisse. + +Noch offen: +- Wer Surveys genau anlegen, aktivieren und freigeben darf. +- Wie Fragetypen und Antwortoptionen modelliert werden. +- Welche Auswertungen im MVP benoetigt werden. 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. +Empfehlung: +- Fachseite arbeitet auf Live-Daten. +- Fuer Benutzer wird bei Freigabe ein stabiler Snapshot veroeffentlicht. +- Snapshot-Versionen muessen nachvollziehbar gespeichert werden. ### 6. Audit Und Storno -Offen: -- Darf weiterhin direkt geloescht werden? -- Oder braucht es kuenftig Storno, Historie und Freigaben? +Status: +- [~] Fachliche Leitplanke geklaert +- [ ] Regelwerk vor Implementierung spezifizieren + +Bereits geklaert: +- Einzahlungen sollen stornierbar sein. +- Stricheintraege sollen loeschbar sein. +- Korrekturen duerfen nur durch Verantwortliche erfolgen. + +Noch offen: +- Ob Freigaben oder Begruendungen erforderlich sind. +- Wie Referenzen auf Ursprungseintraege, Auditfelder und Historie aussehen. +- Wie Importe und Jahresabschluss mit Korrekturen umgehen. Warum blocker: -- Legacy arbeitet vielfach mit direkter Loeschung; das ist fuer SaaS und - Nachvollziehbarkeit meist zu schwach. +- Legacy arbeitet vielfach mit direkter Loeschung; fuer SaaS und Nachvollzieh- + barkeit ist das 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. +## Nichtfunktionale Mindestanforderungen + +Diese Anforderungen muessen vor oder spaetestens waehrend Paket-Spezifikation +explizit beschrieben werden. Sie fehlen aktuell noch in den Legacy-Dokumenten. + +- Datenschutz und Berechtigungskonzept fuer Kontostaende, Mailadressen, + Exporte und Supportinhalte +- Logging und Audit fuer Massenaktionen, Exporte, Freigaben und Integrationen +- Monitoring und Fehlerbenachrichtigung fuer Importe, Mailversand und + Hintergrundprozesse +- Backup/Restore fuer tenantkritische Stammdaten und Bewegungsdaten +- Schutzmechanismen fuer risikoreiche Aktionen: Vorschau, Testmodus, + Vier-Augen-Freigabe, Idempotenz +- Test- und Abnahmekriterien fuer alle MVP-Pakete + +Empfehlung: +- Vorschau und Testmodus sind Mindestanforderung fuer riskante Sammelaktionen + bereits im MVP. +- Vier-Augen-Freigabe ist fuer Jahresauswertung, Massenmail, Importlaeufe und + gebuendelte Stornoaktionen vorzusehen. +- Die Vier-Augen-Freigabe muss tenantweit konfigurierbar und deaktivierbar + sein. ## Bereits Tragfaehige Grundlagen Im SaaS-Geruest @@ -127,6 +253,91 @@ Einordnung: - Es ist nicht gut genug, um alle Themen parallel ohne weitere Fachspezifikation produktiv zu bauen. +## Empfohlene Projektphasen + +### Phase 0. Architektur- und Fachentscheidungen + +Ziel: +- Blocker aufloesen, damit nachfolgende Pakete sauber geschnitten sind. + +Enthaelt: +- Identity-Zielbild +- Rollen- und Rechte-Matrix +- Audit-/Storno-Regeln +- Support-Workflow +- Survey-Freigabemodell +- Mindestanforderungen fuer Betrieb, Sicherheit und Tests + +Ergebnis: +- Verbindliche Leitplanken fuer Umsetzung und Abnahme + +### Phase 1. Basis Und Content MVP + +Ziel: +- Schnell ein erstes nutzbares Modul liefern und gleichzeitig die + Tenant-Grundlagen stabilisieren. + +Enthaelt: +- Content-MVP fuer Hinweise und FAQ +- Standardvorlagen mit Tenant-Override +- erste Rollenpruefungen auf Basis der festgelegten Matrix +- `mailausgebe.php` nicht als Produktfunktion uebernehmen + +Ergebnis: +- Erstes produktiv brauchbares Fachmodul mit klarer Zustands- und Rechtebasis + +### Phase 2. Operatives Ledger + +Ziel: +- Buchungen, Einzahlungen und Korrekturen revisionsfaehig machen. + +Enthaelt: +- operative Strich- und Einzahlungserfassung +- Audit-/Storno-Modell +- Basis fuer spaetere Importe und Zahlungsabgleiche + +Ergebnis: +- Nachvollziehbare Buchungslogik statt Legacy-Loeschverhalten + +### Phase 3. Kommunikation Und Self-Service + +Ziel: +- Nutzernahe Prozesse und Supportwege in den regulaeren App-Rahmen ueberfuehren. + +Enthaelt: +- Support Requests MVP +- Self-Service-Elemente rund um Dashboard und Anfragen +- sichere Serienmail- und Kommunikationsprozesse + +Ergebnis: +- Nachvollziehbarer Kommunikationsprozess statt unkontrollierter Einzeltools + +### Phase 4. Surveys + +Ziel: +- Tenant-faehige Survey-Erstellung, Auswertung und kontrollierte Freigabe. + +Enthaelt: +- Survey Admin MVP +- Survey Publishing fuer Benutzer +- Rollen- und Sichtbarkeitsregeln + +Ergebnis: +- Nutzbares Survey-Modul fuer operativen Betrieb und spaetere Erweiterungen + +### Phase 5. Automatisierung Und Integrationen + +Ziel: +- Auf den stabilen MVP-Modulen aufsetzen und Integrationen sicher erweitern. + +Enthaelt: +- Payment Reconciliation +- Catch-all Mailbox Integration +- weitergehende Identity-Integrationen je Tenant + +Ergebnis: +- Kontrollierte Automatisierung statt zu frueher Integrationskomplexitaet + ## Empfohlene Reihenfolge Fuer Spezialistenpakete ### Paket 1. Identity Baseline @@ -135,12 +346,13 @@ Ziel: - Zielarchitektur fuer Login und Identitaetsverknuepfung festziehen Scope: -- OIDC-/ADFS-Entscheid dokumentieren +- Zielpfad dokumentieren - Provider-Konfiguration pro Tenant - Benutzeridentitaeten sauber mappen +- Regeln fuer Erstlogin und Dubletten Ergebnis: -- Eine stabile Basis fuer alle spaeteren Rollen- und Zugriffsthemen +- Stabile Basis fuer Rollen- und Zugriffsthemen Status: - [ ] Noch nicht spezifiziert @@ -155,10 +367,11 @@ Scope: - Plattform-Admin - Tenant-Admin - Mitglied -- optional Finance, Support, Survey-Manager +- optionale Spezialrollen wie Finance, Support, Survey-Manager +- Rechte-Matrix pro Aktion und Objekt Ergebnis: -- Klare Berechtigungsbasis fuer Payments, Support und Surveys +- Klare Berechtigungsbasis fuer Payments, Support, Surveys und Exporte Status: - [ ] Noch nicht spezifiziert @@ -175,10 +388,10 @@ Scope: - aktiv/inaktiv - Sortierung - Sichtbarkeit bis Datum -- optionale Standardvorlage als Startbestand +- Standardvorlage plus Tenant-Override Ergebnis: -- Erstes direkt nutzbares Fachmodul mit bereits passendem Datenmodell +- Erstes direkt nutzbares Fachmodul mit passendem Datenmodell Status: - [X] Fachlich fast schnittreif @@ -188,7 +401,7 @@ Status: Ziel: - Anfragen Benutzer -> Kaffeelistenverantwortliche -- Anfragen Verantwortliche -> zentrale Administration +- Anfragen Verantwortliche -> Plattform-Administration Scope: - `support_requests` @@ -199,13 +412,14 @@ Scope: - Ziel - Status - Zeitstempel +- Routing- und Eskalationsregeln Ergebnis: -- Ein nachvollziehbarer Kommunikationsprozess statt nackter Mailweiterleitung +- Nachvollziehbarer Kommunikationsprozess statt nackter Mailweiterleitung Status: -- [ ] Vorher Workflow-Entscheid noetig -- [ ] Danach implementierbar +- [X] Zielbild entschieden +- [ ] Workflow und Statusmodell spezifizieren ### Paket 5. Payment Configuration MVP @@ -219,13 +433,14 @@ Scope: - aktivierte Methoden - Hinweise fuer Benutzer - tenantbezogene Zahlungsparameter +- Vorbereitung fuer spaetere Reconciliation Ergebnis: - Saubere Grundlage fuer spaetere Automatisierung Status: +- [~] Teilweise geklaert - [ ] Vorher Fachmodell vervollstaendigen -- [ ] Danach implementierbar ### Paket 6. Ledger Audit Und Korrekturen @@ -233,10 +448,12 @@ Ziel: - Buchungen sicher korrigieren statt direkt loeschen Scope: -- Storno statt Hard Delete +- Storno fuer Einzahlungen +- Loeschung fuer Stricheintraege - Auditfelder - Referenzen auf Ursprungseintraege - Begruendung oder Freigabeoption +- Regeln fuer Import- und Jahresabschlusskorrekturen Ergebnis: - Nachvollziehbares Buchungsmodell @@ -256,13 +473,14 @@ Scope: - Aktivierungszeitraum - Ergebnisfreigabe - Auswertung fuer Tenant-Admins +- Rollen fuer Erstellung und Freigabe Ergebnis: - Nutzbares Survey-Modul fuer den operativen Betrieb Status: +- [~] Teilweise geklaert - [ ] Vorher Antwortoptionen und Freigabemodell ergaenzen -- [ ] Danach implementierbar ### Paket 8. Survey Publishing Fuer Benutzer @@ -324,37 +542,50 @@ 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 +- Rollenmatrix und Rechtekonzept als Spezifikationspaket +- Tenant Payment Configuration als Fachmodell +- Support-Requests Datenmodell als Vorarbeit +- Survey-Admin-Konzept als Spezifikationspaket Diese Themen sollten noch nicht in Produktcode parallel umgesetzt werden: - Catch-all-Mailbox fuer PayPal -- finale Identity-Integration ohne Architekturentscheid +- finale Identity-Integration ohne Detailkonzept fuer Mapping und Fallback - Survey-Publishing fuer Benutzer ohne Freigabemodell - Audit-/Storno-Implementierung ohne fachliche Korrekturregeln +- Serienmail- oder Jahresabschlussfunktionen ohne Schutzmechanismen und Testmodus ## Konkrete Naechste Entscheidungsliste -- [ ] OIDC mit ADFS als Zielpfad bestaetigen oder AD-/LDAP-Abgleich bevorzugen -- [ ] Rollenmatrix festlegen -- [ ] Support Requests als Mailweiterleitung oder Vorgangssystem definieren +### Entscheidungen Mit Hoher Prioritaet + +- [ ] Rechte-Matrix finalisieren +- [ ] Support-Status, Routing und Eskalationsregeln festlegen +- [ ] Storno-/Loeschregeln fuer Buchungen finalisieren +- [ ] Identity-Detailregeln fuer Erstlogin, Fallback und Dubletten festlegen + +### Entscheidungen Mit Mittlerer Prioritaet + - [ ] FAQ/Mailtexte als Standardvorlage mit Tenant-Override bestaetigen -- [ ] Survey-Freigabemodell fuer Benutzer festlegen -- [ ] Storno/Audit statt direkter Loeschung bestaetigen +- [X] Survey-Freigabemodell fuer Benutzer als Snapshot-Veroeffentlichung + vorsehen +- [X] Payment Configuration MVP ohne Reconciliation, aber mit technischer + Vorbereitung festlegen + +### Entscheidungen Mit Nachgelagerter Prioritaet + - [ ] Catch-all-Mailbox ausdruecklich als spaeteres Integrationspaket bestaetigen +- [ ] Jahresauswertung und Bonuslogik als konfigurierbaren Prozess spezifizieren +- [ ] Zusatzfelder im Benutzerprofil tenantweit festlegen ## 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. +1. Phase 0 als kurzer Spezifikations- und Entscheidungs-Sprint +2. Content-MVP als erstes lieferbares Fachpaket +3. Rollenmatrix und Payment Configuration als Basis fuer weitere Module +4. Support Requests MVP und Ledger Audit/Korrekturen +5. Survey Admin MVP und danach Survey Publishing +6. Erst danach Payment-Reconciliation, Mailbox-Import und komplexere + Identity-Integrationen