torsten/trainingstagebuch
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
ac97332e6fd32e47115895e70562cf36bbd722fc
trainingstagebuch/docs/club-outstanding-plan.md
Torsten Schulz (local) ac97332e6f
All checks were successful
Deploy tt-tagebuch / deploy (push) Successful in 1m0s
Details
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
Raw Blame History

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.

Reference in New Issue View Git Blame Copy Permalink