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

• Kommunikation
• Historie
• Archiv
• Restliche Club-UI-Absicherung in den Kernviews
• Danach erst das mein-tt.de-Produkt inhaltlich weiter 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.

Phase 2: Kommunikation produktiv absichern

Ziel:

• Nachrichtenfluss nicht nur funktional, sondern praxisnah robust machen.

Arbeitspakete:

• SMTP real testen, inklusive Zustellprotokoll und Fehlerfaelle.
• Optional Reply-To pro Verein oder Kommunikationsvorlage sauber ergaenzen.
• Dokumentanhaenge fuer Nachrichten und Vorlagen einfuehren.
• 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.

Phase 3: Historie und Archiv vertiefen

Ziel:

• Vergaengliche Vorgange muessen spaeter besser auffindbar und nachvollziehbar sein.

Arbeitspakete:

• Historie nach Modulen und Vorgangstypen filtern.
• Historie exportierbar machen.
• Historie mit Zielobjekten und Querverweisen versehen.
• Archiv um weitere Entitaeten erweitern.
• Archivsuche und Schnellfilter verbessern.

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.

Phase 4: Restliche Club-UX verdichten

Ziel:

• Das Dashboard und die Detailmodule sollen gleiche Sprache sprechen.

Arbeitspakete:

• Dashboard-Schnellzugriffe weiter auf Tagesgeschaeft trimmen.
• Verlinkungen zwischen Dashboard, Mitgliedern, Zahlungen, Kommunikation und Archiv schaerfen.
• Kleine Inkonsistenzen in Statusworten, Akzentfarben und Listenlabels bereinigen.

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

• SMTP-Test fuer Kommunikation mit realer Zieladresse und dokumentiertem Ergebnis.
• Dokumentanhaenge fuer Kommunikation und Vorlagen.
• Historie: Filter und Export.
• Archiv: weitere Objektklassen und Suche.
• Club-UI-Smoke-Check fuer Aufgaben, Kommunikation, Konten und Rechnungen.

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.