# 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.