trainingstagebuch/docs/club-outstanding-plan.md

Club-Produkt: Ausbau und Absicherung

Stand: 2026-06-25

Ziel

Die vorhandenen Club-Module sollen nicht mehr nur "vorhanden", sondern im Alltag stabil und nachvollziehbar nutzbar sein. Der Schwerpunkt liegt jetzt auf zwei Dingen:

• Ausbau der noch klar erkennbaren Restthemen.
• Absicherung der bereits fertig wirkenden Arbeitsbereiche gegen Kantenfaelle, Rechteprobleme und unklare Zustande.

Aktueller Fokus

Die Reihenfolge folgt Abhaengigkeiten und Betriebsrisiko: Erst muessen die vorhandenen Kernarbeitsbereiche bei Clubwechsel, Rechten und Fehlern stabil sein. Danach wird der reale Kommunikationsversand abgesichert. Erst auf dieser Basis lohnt sich der Ausbau von Nachvollziehbarkeit (Historie und Archiv) und der letzte UX-Feinschliff.

1. Club-UI-Absicherung in den Kernviews
2. Kommunikation produktiv absichern
3. Historie und Archiv vertiefen
4. Restliche Club-UX und Dashboard verdichten
5. Erst danach das mein-tt.de-Produkt inhaltlich ausbauen

Arbeitsreihenfolge

Phase 1: Absicherung der bestehenden Club-Views

Status: in Arbeit

Ziel:

• Keine haengenden Formulare bei Reload, Clubwechsel oder Auswahlwechsel.
• Read-only-Zustaende sind sichtbar und verhindern keine Navigation.
• Lade- und Fehlermeldungen sind konsistent und eindeutig.

Konkrete Teilaufgaben:

• ClubTasksView.vue: Sicherstellen, dass selectedTask und form beim Clubwechsel, bei leerer Liste und nach Loesch-/Archivaktionen sauber getrennt werden.
• ClubCommunicationView.vue: selectedThread, threadForm, groupForm, templateForm und messageForm beim Clubwechsel und nach Auswahlwechseln komplett zuruecksetzen.
• ClubAccountsView.vue: selectedAccount, selectedTransaction, form und transactionForm in jedem Ruecksprung sauber bereinigen.
• ClubInvoicesView.vue: selectedInvoice, selectedParty, invoiceForm und partyForm beim Clubwechsel und bei leeren Selektionen auf Default bringen.
• Read-only-Hinweise auf jeder der vier Views vereinheitlichen, damit ein Nutzer mit fehlenden Rechten nicht erst in die Formulare klickt, um zu merken, dass keine Bearbeitung moeglich ist.
• Ladezustände und Fehlerbanner auf eine einheitliche Form bringen, damit Reload und Fehlerfall nicht unterschiedlich wirken.
• Ein kurzer Smoke-Check je View nach der Aenderung: Liste laden, Element auswaehlen, Auswahl loeschen, Club wechseln, erneut laden.

Gepruefte Kantenfaelle:

• Club wird gewechselt, waehrend ein Detailformular offen ist.
• Datenquelle liefert eine leere Liste und der zuletzt selektierte Datensatz existiert nicht mehr.
• Nutzer hat nur Leserechte, soll aber trotzdem eine klare Orientierung haben.
• Reload erfolgt waehrend ein Formular bereits mit Daten befuellt ist.

Fertig, wenn:

• Die vier Kernviews ohne manuelle Nacharbeit zwischen Liste, Detail und Neu-Anlage wechseln.
• Beim Clubwechsel keine Formularwerte aus dem vorherigen Club sichtbar bleiben.
• Read-only-Nutzer die Bereiche verstehen, ohne in kaputte Aktionen zu laufen.

Abnahmefolge je View:

1. Mit Schreibrechten Liste laden, Datensatz oeffnen, bearbeiten, Auswahl loeschen und neu anlegen.
2. Waerend ein Detail offen ist den Club wechseln und pruefen, dass keine alten Werte bleiben.
3. Mit Leserechten laden und pruefen, dass Orientierung, Navigation und Hinweise funktionieren.
4. Leere Liste, Reload und einen API-Fehler pruefen.

Prioritaet innerhalb der Phase:

1. ClubTasksView.vue und ClubCommunicationView.vue (taegliche, zustandsreiche Arbeitsbereiche).
2. ClubAccountsView.vue und ClubInvoicesView.vue (finanzielle Folgerisiken).

Phase 2: Kommunikation produktiv absichern

Ziel:

• Nachrichtenfluss nicht nur funktional, sondern praxisnah robust machen.

Arbeitspakete:

1. SMTP real testen, inklusive Zustellprotokoll, Konfigurationsfehlern und Fehlerfaellen.
2. Ergebnis und notwendige Betriebsparameter pro Verein dokumentieren.
3. Optional Reply-To pro Verein oder Kommunikationsvorlage sauber ergaenzen.
4. Dokumentanhaenge fuer Nachrichten und Vorlagen einfuehren.
5. Serienvorlagen und wiederkehrende Nachrichtentypen vorbereiten.

Fertig, wenn:

• Eine Testzustellung je Verein reproduzierbar gelingt.
• Fehlende SMTP-Konfiguration klar und frueh sichtbar wird.
• Nachrichten mit Anhaengen und Vorlagen ohne Sonderlogik im Alltag einsetzbar sind.

Hinweis zur Abhaengigkeit:

• Anhaenge und Serienvorlagen erst nach erfolgreichem SMTP-Smoke-Test umsetzen.
• Der SMTP-Test braucht eine reale, freigegebene Versandkonfiguration und mindestens eine Testadresse.

Phase 3: Historie und Archiv vertiefen

Ziel:

• Vergaengliche Vorgange muessen spaeter besser auffindbar und nachvollziehbar sein.

Arbeitspakete:

1. Historie nach Modulen und Vorgangstypen filtern.
2. Historie mit Zielobjekten und Querverweisen versehen.
3. Archivsuche und Schnellfilter verbessern.
4. Archiv um weitere Entitaeten erweitern.
5. Historie exportierbar machen.

Fertig, wenn:

• Vorstand oder Verwaltung einen Vorgang aus Historie oder Archiv ohne Umweg wiederfinden kann.
• Wichtige Clubobjekte nicht nur archiviert, sondern auch wieder auffindbar und verlinkt sind.

Hinweis zur Abhaengigkeit:

• Export erst nach Festlegung von Filtern, Zielobjekten und darzustellenden Feldern bauen; sonst wird ein instabiles Datenformat festgeschrieben.

Phase 4: Restliche Club-UX verdichten

Ziel:

• Das Dashboard und die Detailmodule sollen gleiche Sprache sprechen.

Arbeitspakete:

1. Verlinkungen zwischen Dashboard, Mitgliedern, Zahlungen, Kommunikation und Archiv schaerfen.
2. Dashboard-Schnellzugriffe mit den tatsaechlich haeufigsten Tagesaktionen abgleichen und verdichten.
3. Kleine Inkonsistenzen in Statusworten, Akzentfarben und Listenlabels bereinigen.
4. Einen abschliessenden bereichsuebergreifenden Smoke-Check fuer Navigation, Rechte und leere Zustaende ausfuehren.

Fertig, wenn:

• Der Einstieg immer zur naechsten sinnvollen Aktion fuehrt.
• Die wichtigsten Statuswerte nicht doppelt oder widerspruechlich gezeigt werden.

Phase 5: Player-Produkt erst danach

Ziel:

• mein-tt.de bekommt nur dann neue Inhalte, wenn die Club-Seite stabil ist.

Arbeitspakete:

• Anforderungen fuer Spieleransichten separat sammeln.
• Keine Club-spezifischen Workflows mehr in das Player-Produkt ziehen.
• Neue Spielerfeatures nur gegen eigene Prioritaeten und nicht als Restverwertung der Club-Roadmap planen.

Nicht als naechstes anfassen

• Generelles Beitrags- und Tarifsystem mit Familienlogik, Alterslogik und Gueltigkeitszeitrainen.
• Weitere grosse Produktumbauten ohne klaren Nutzen fuer den Club-Alltag.
• Zusätzliche Club-Module, solange die bestehenden Workflows noch nicht absicherungsfest sind.

Konkrete naechste Tickets

Jetzt

1. Club-UI-Smoke-Check und Kantenfallkorrekturen fuer Aufgaben und Kommunikation.
2. Club-UI-Smoke-Check und Kantenfallkorrekturen fuer Konten und Rechnungen.
3. Einheitliche Read-only-, Lade- und Fehlerzustaende in den vier Kernviews.

Danach

4. SMTP-Test fuer Kommunikation mit realer Zieladresse und dokumentiertem Ergebnis.
5. Sichtbare Behandlung fehlender oder fehlerhafter SMTP-Konfiguration nachziehen.
6. Reply-To je Verein/Vorlage entscheiden und bei Bedarf umsetzen.
7. Dokumentanhaenge fuer Kommunikation und Vorlagen.
8. Serienvorlagen und wiederkehrende Nachrichtentypen.

Anschliessend

9. Historie: Filter nach Modul und Vorgangstyp sowie Querverweise auf Zielobjekte.
10. Archiv: Suche, Schnellfilter und danach weitere Objektklassen.
11. Historie: Export auf Basis der stabilen Filter- und Objektstruktur.
12. Dashboard-Deep-Links, Schnellzugriffe und Statuskonsistenz abschliessen.

Abhaengigkeiten

• SMTP-Test braucht eine real erreichbare Versandkonfiguration.
• Historie-Export braucht klare Zielobjekt- und Filterdefinitionen.
• Archiv-Erweiterungen sollten auf bereits vorhandene Dokument-, Rechnungs- und Beitragsdaten aufsetzen.

Erwartetes Ergebnis

Nach dieser Runde sind die Club-Bereiche nicht nur vorhanden, sondern im Alltag kontrollierbar, nachvollziehbar und ausreichend robust fuer den produktiven Einsatz eines Vereins. Danach kann der Fokus auf neue inhaltliche Produktarbeit wechseln.