Begegnung speichert „gespielt“ und „bestätigt“ doppelt zum Resultat #156

New issue

Open

opened 2026-10-28 14:51:35 +00:00 by claude · 0 comments

claude commented

2026-10-28 14:51:35 +00:00

Collaborator

Befund

Eine Begegnung hat zwei Status:

Begegnung (TeamMatch.status): offen → terminiert → gespielt → bestätigt
Resultat (TeamMatch.resultStatus): Entwurf → eingereicht → (Korrektur verlangt) → bestätigt

„gespielt“ und „bestätigt“ an der Begegnung sind eine Kopie des Resultats. An allen sechs
Schreibstellen werden beide gemeinsam gesetzt, nie einzeln:

Resultat	Begegnung
eingereicht	gespielt
Korrektur verlangt	bleibt gespielt
bestätigt	bestätigt
gelöscht (Verband hebt auf)	zurück auf terminiert bzw. offen

Stellen: TeamMatchResultService (Einreichen, Forfait, Bestätigen, Korrektur durch den Verband,
Aufheben), CaptainReminderService (automatische Bestätigung), TournamentWriteService,
SeasonSeedService. Auch eine w.o.-Wertung läuft über das Resultat (ADR 0029) und trennt die
beiden nicht.

Einen eigenen Sinn hat der Begegnungsstatus nur beim Termin: offen und terminiert.

Wie es dazu kam

05.06., Spec Liga-Schattenbetrieb (Entwurf): Begegnung offen → vorgeschlagen → bestätigt
(= Termin angenommen) → gespielt; das Resultat hatte einen eigenen Status. Zwei verschiedene
„bestätigt“.
06.07., Liga-Datenmodell: gebaut als offen → terminiert → gespielt → bestätigt, ohne
Begründung. Ein Resultat gab es noch nicht.
20.07., Captain-Block (V26): result_status kam dazu, laut Spec „getrennt vom bestehenden
status“, die Abläufe derselben Spec setzen aber beide gemeinsam. Seitdem gekoppelt.

Vorschlag

Die Begegnung trägt nur noch den Termin (offen, terminiert); ob sie gespielt oder bestätigt ist,
liest sie aus dem Resultat. Gelesen wird „gespielt/bestätigt“ am Begegnungsstatus heute in
TeamMatchRepository (vier Abfragen), ScheduleLockService und sechs Dateien im Portal.

Bis dahin ändert im Zuschnitt nach ADR 0033 ein TeamMatchFlow beide Felder gemeinsam, damit sie
nicht auseinanderlaufen (Service-Zuschnitt,
entschieden 28.10.). Ist die Kopie weg, teilt er sich in Termin und Resultat.

Kein fachlicher Unterschied für die Nutzer; reiner Umbau des Datenmodells.

## Befund Eine Begegnung hat zwei Status: - **Begegnung** (`TeamMatch.status`): offen → terminiert → gespielt → bestätigt - **Resultat** (`TeamMatch.resultStatus`): Entwurf → eingereicht → (Korrektur verlangt) → bestätigt „gespielt“ und „bestätigt“ an der Begegnung sind eine Kopie des Resultats. An allen sechs Schreibstellen werden beide gemeinsam gesetzt, nie einzeln: | Resultat | Begegnung | |---|---| | eingereicht | gespielt | | Korrektur verlangt | bleibt gespielt | | bestätigt | bestätigt | | gelöscht (Verband hebt auf) | zurück auf terminiert bzw. offen | Stellen: `TeamMatchResultService` (Einreichen, Forfait, Bestätigen, Korrektur durch den Verband, Aufheben), `CaptainReminderService` (automatische Bestätigung), `TournamentWriteService`, `SeasonSeedService`. Auch eine w.o.-Wertung läuft über das Resultat (ADR 0029) und trennt die beiden nicht. Einen eigenen Sinn hat der Begegnungsstatus nur beim Termin: offen und terminiert. ## Wie es dazu kam - **05.06.**, Spec Liga-Schattenbetrieb (Entwurf): Begegnung offen → vorgeschlagen → *bestätigt* (= Termin angenommen) → gespielt; das Resultat hatte einen eigenen Status. Zwei verschiedene „bestätigt“. - **06.07.**, Liga-Datenmodell: gebaut als offen → terminiert → gespielt → bestätigt, ohne Begründung. Ein Resultat gab es noch nicht. - **20.07.**, Captain-Block (V26): `result_status` kam dazu, laut Spec „getrennt vom bestehenden `status`“, die Abläufe derselben Spec setzen aber beide gemeinsam. Seitdem gekoppelt. ## Vorschlag Die Begegnung trägt nur noch den Termin (offen, terminiert); ob sie gespielt oder bestätigt ist, liest sie aus dem Resultat. Gelesen wird „gespielt/bestätigt“ am Begegnungsstatus heute in `TeamMatchRepository` (vier Abfragen), `ScheduleLockService` und sechs Dateien im Portal. Bis dahin ändert im Zuschnitt nach ADR 0033 ein `TeamMatchFlow` beide Felder gemeinsam, damit sie nicht auseinanderlaufen ([Service-Zuschnitt](https://forgejo.mydevlab.work/olli/sffs-tt-basel/src/branch/main/docs/2026-10-28-service-zuschnitt.md), entschieden 28.10.). Ist die Kopie weg, teilt er sich in Termin und Resultat. Kein fachlicher Unterschied für die Nutzer; reiner Umbau des Datenmodells.