Files
trainingstagebuch/docs/club-outstanding-plan.md
Torsten Schulz (local) ac97332e6f
All checks were successful
Deploy tt-tagebuch / deploy (push) Successful in 1m0s
feat: Enhance club payment claims and task automation
- Added `paid_amount_cents` column to `club_payment_claims` for better tracking of payments.
- Implemented compatibility checks for the new column in `clubPaymentClaimService` and `clubTaskAutomationService`.
- Updated various views to handle read-only states when editing is not allowed.
- Refactored forms in `ClubAccountsView`, `ClubInvoicesView`, `ClubTasksView`, and `ClubCommunicationView` to use factory functions for cleaner code.
- Introduced a new migration script to add the `paid_amount_cents` column if it doesn't exist and initialize it for existing paid claims.
- Created a detailed plan for enhancing club features and ensuring stability in existing modules.
2026-07-13 17:01:13 +02:00

5.7 KiB

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.