Skip to content

Add 7-day trend to overall ranking (placement change + last point gain) - #963

Open
artikcoder wants to merge 1 commit into
XCCup:mainfrom
artikcoder:feature/overall-ranking-trend
Open

Add 7-day trend to overall ranking (placement change + last point gain)#963
artikcoder wants to merge 1 commit into
XCCup:mainfrom
artikcoder:feature/overall-ranking-trend

Conversation

@artikcoder

@artikcoder artikcoder commented Aug 28, 2026

Copy link
Copy Markdown

Closes #962

Was ändert sich

Neue Spalte "7-Tage-Trend" in der Standard-Gesamtwertung (aktuelle Saison, ohne Filter):

  • Platz-Pfeil: ▲N / ▼N seit dem letzten relevanten Ereignis für diese Person, "–" wenn nichts zu zeigen ist.
  • Punkte-Badge: "+X P", nur sichtbar wenn die eigenen Punkte seit dem letzten eigenen Flug-Ereignis gestiegen sind.
  • Fett-Markierung des zuletzt eingereichten Top3-Flugs, solange der angezeigte Trend durch ein eigenes Ereignis (nicht durch Verdrängung) ausgelöst wurde.
  • Ein einmal gesetzter Trend bleibt stehen, bis entweder ein neues relevantes Ereignis für diese Person eintritt, oder spätestens nach 7 Tagen ohne ein solches Ereignis (automatischer Ablauf).

Details zur Motivation und den einzelnen Fällen (1–5) stehen in #962.

Technischer Ansatz

  • Keine neue Tabelle/Migration: Das bestehende Result-Model (season/type/result-JSON) wird für die laufende Saison mit einem neuen type ("overallSnapshot") als Vergleichs-Baseline wiederverwendet - bisher diente es nur als Archiv für abgeschlossene Saisons.
  • Neuer Service server/service/RankingSnapshotService.ts: Diffing-Logik. Pro Person wird Platz/Punkte zum Zeitpunkt ihres letzten eigenen Ereignisses als Referenz gespeichert. Verdrängungen durch andere aktualisieren nur die Anzeige, nie diese Referenz - dadurch bleibt eine Tendenz über beliebig viele fremde Zwischen-Ereignisse hinweg korrekt bestehen.
  • Hook: ResultService.refreshOverallRankingSnapshot(userId) wird an allen bestehenden Stellen in FlightController.ts aufgerufen, an denen sich Flugdaten ändern können (Upload, Bearbeitung, Löschung, Annahme/Ablehnung einer Luftraumverletzung, Admin-Änderung) - kein neuer Cronjob.
  • Lesen: ResultService.getOverall() reichert die Ergebnisse nur für die ungefilterte Standardansicht um die Trend-Felder an.
  • Umfang bewusst begrenzt: nur die Standard-Gesamtwertung. Andere Wertungen (Damen, Senioren, Vereine, Teams, Newcomer, gefilterte Ansichten) sind mit demselben Mechanismus später erweiterbar, aber hier nicht enthalten.

Getestet

Lokal (Postgres + Server + Client ohne Docker) gegen die mitgelieferten Testdaten (/testdata/seed) durchgespielt:

  • Eigener Flug verbessert Platzierung → Pfeil + Punkte-Badge, korrekt berechnet
  • Fremde Verdrängung (ohne eigenes Zutun) → nur Pfeil, kein Badge, keine Fett-Markierung
  • Unabhängige Änderung weiter unten in der Wertung → eigene Anzeige bleibt exakt unverändert (Persistenz)
  • Eigener neuer Flug ohne Auswirkung (nicht in Top 3) → Anzeige wird auf "–" zurückgesetzt
  • Eigener neuer Flug mit Punkten, aber ohne Platzverbesserung → "–" beim Pfeil, Punkte-Badge trotzdem sichtbar
  • 7-Tage-Ablauf → nach Ablauf zeigt sich wieder "–", unabhängig davon, ob seitdem etwas passiert ist

Offene Fragen / Diskussionspunkte

Falls ihr eine andere Herangehensweise bei der Datenhaltung oder dem Umfang bevorzugt, gerne Bescheid geben - lässt sich noch anpassen, bevor gemergt wird.

Shows per pilot in the default overall ranking:
- a rank-change arrow (up/down places) since their own last flight event
- the point gain from their own last flight event, if any
- bold highlight on their most recently submitted top flight, while that
  trend is still active and self-caused

Persists across unrelated changes elsewhere in the ranking, resets on the
pilot's own next flight event, and expires automatically after 7 days.

Reuses the existing Result model (season/type/result-JSON, new type
'overallSnapshot') as the comparison baseline - no new table/migration.
Hooked into the existing flight-mutation points in FlightController
(upload, edit, delete, accept/reject violation, admin change).

See issue discussion for the full design rationale and test scenarios.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Vorschlag: 7-Tage-Trend in der Gesamtwertung (Platz-Veränderung + letzter Punktgewinn)

1 participant