stammtisch-hersbruck/TODO.md
Daniel Michelberger b1594d99c4 docs: TODO gegen die produktive Instanz abgeglichen
Sechs der elf Migrationen sind laengst gelaufen - der Backend-Deploy hat
alles bis 1754500900 mitgenommen. Die Datei behauptete weiter, es stehe
alles aus, samt eines Symptoms ("Only superusers can perform this action"),
das es so nicht mehr gibt.

Die Tabelle sagt jetzt je Migration, was gelaufen ist und was nicht, und
benennt, welche Funktionen bis zum naechsten Deploy ins Leere laufen.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014dh9W1i7aLSdPYJzQPid5o
2026-09-02 16:14:35 +02:00

5.5 KiB

Offene Punkte

Stand: 2026-09-02, abgeglichen mit der produktiven Instanz. Die fachlichen Entscheidungen sind gefallen und gebaut; was hier steht, passiert außerhalb des Repos oder wartet auf den nächsten Deploy.

Vor dem nächsten Deploy

PUBLIC_CARTO_API_KEY in Coolify setzen

Die Kartenkacheln kommen von CARTO. Der Schlüssel muss den Browser erreichen, deshalb das PUBLIC_-Präfix — ohne das reicht SvelteKit ihn nicht weiter.

Gelesen wird er über $env/dynamic/public, das heißt: Die Variable muss in der Laufzeitumgebung des node build-Prozesses stehen, nicht nur zur Buildzeit. In Coolify als normale Umgebungsvariable eintragen genügt. Fehlt sie, laufen die Kacheln ohne Schlüssel weiter — die Karte bleibt also sichtbar.

Migrationen: sechs gelaufen, fünf offen

Abgeglichen mit api.stammtisch-hersbruck.de (nur gelesen): Der Backend-Deploy hat alles bis 1754500900 mitgenommen, ab 1754501000 steht es noch aus.

Datei Was sie tut Stand
1754500500_riders_user_and_admin_rules riders.user, Fahrerpflege nur Teamleitung, users.viewRule/createRule gelaufen
1754500600_events_dates_instead_of_status events.status raus, starts/ends rein gelaufen
1754500700_trail_status_meta trails.status_changed, status_by gelaufen
1754500800_trail_markers_custom trail_markers.label/icon, flag optional gelaufen
1754500900_users_superadmin users.superadmin samt Schutz vor Selbstbeförderung gelaufen
1754501000_teams_logo teams.logo offen
1754501100_trails_status_report Mitglieder dürfen den Trail-Zustand melden offen
1754501200_users_list_for_invites users.listRule gelockert (Kontosuche) offen
1754501300_event_participants neue Collection, verschiebt Daten, entfernt riders.event/number offen
1754501400_events_timing_participation events.timing/participation offen
1754501500_event_series event_series, events.series offen

Bis zum nächsten Deploy laufen deshalb ins Leere: Team-Logo, Zustandsmeldung durch Mitglieder, Kontosuche per E-Mail, Teilnehmerlisten, die Event-Schalter und die Serien. Die Oberfläche dafür ist da und wird beim Speichern eine Fehlermeldung von PocketBase zeigen.

Zwei Dinge sind beim Nachziehen nicht zurückzunehmen:

  1. 1754501300 legt für jeden Fahrer mit Event einen Teilnehmer an und entfernt danach riders.event und riders.number. Eine Startnummer an einem Fahrer ohne Event hat danach keinen Platz mehr und geht verloren — sie war ohnehin nirgends sichtbar, weil alle Listen nach Event filterten.
  2. Bestehende Events werden auf timing = true und participation = geschlossen gesetzt. Genau so wurden sie bisher benutzt; wer einen Stammtisch daraus machen will, schaltet die Zeitnahme im Dialog ab.

Ebenfalls bewusst so: Nach 1754501200 kann jeder Eingeloggte Konten auflisten, damit sich bestehende Konten per E-Mail ins Team holen lassen. E-Mail-Adressen bleiben über emailVisibility verborgen.

Typen einmal neu erzeugen

frontend/src/lib/types.d.ts wurde bei allen Schema-Änderungen von Hand gepflegt. Grund: pocketbase-typegen braucht native sqlite3-Bindings, die in der Arbeitsumgebung nicht gebaut werden durften.

cd frontend && npm run generate-pocketbase-types

Die Datei sollte danach unverändert bleiben. Tut sie es nicht, gilt das Ergebnis des Generators.

Regeln einmal durchspielen

Die Zugriffsregeln der neuen Collections konnten nirgends laufen — weder Docker noch eine lokale PocketBase-Instanz standen zur Verfügung. Sie sind nach dem Muster der vorhandenen Collections geschrieben, aber ungetestet. Nach dem Deploy einmal ausprobieren:

  • Ein einfaches Teammitglied trägt sich bei einem offenen Event selbst ein.
  • Dasselbe bei einem Event mit Bestätigung — es muss als „Angefragt" landen, nicht als „Dabei".
  • Bei einem geschlossenen Event darf es gar nicht gehen.
  • Ein Mitglied meldet einen Trail-Zustand (muss gehen) und versucht, den Namen des Trails zu ändern (darf nicht gehen).

Der Selbsteintrag setzt außerdem voraus, dass das Konto der Person mit einem Fahrer verknüpft ist (Einstellungen → Fahrer → Konto). Ohne Verknüpfung erscheint der Knopf gar nicht erst.

Logo des Stammtischs zuordnen

teams.logo gibt es ab 1754501000. Solange nichts hinterlegt ist, zeigt die App weiterhin das Wappen aus static/ — für den Stammtisch Hersbruck sieht es also unverändert aus. Wer es als Datei am Team haben will, lädt es nach dem Deploy unter Einstellungen → Team → Logo hoch.

Kleinigkeiten

  • Wer Regeln direkt im PocketBase-Admin ändert, hinterlässt keine Spur im Repo. Die Migrationen bleiben die Quelle: Sie setzen dieselben Werte noch einmal und überschreiben eine abweichende Handänderung stillschweigend.
  • Die Rolle Superadmin ist gesetzt, gibt in der App aber noch keine besonderen Rechte. Sie ist bewusst nur in PocketBase vergebbar: Die updateRule der users-Collection schließt superadmin vom Selbstsetzen aus. Sobald klar ist, was sie dürfen soll, kommen die Regeln dazu.
  • Flag-Typen sind teamspezifisch. Ein neues Team bekommt beim Anlegen den hartkodierten Standardsatz aus trailFlags.svelte.ts und kann ihn frei ändern.
  • Serien erzeugen bis zu zwölf Termine je Klick und überspringen, was schon angelegt ist. Ein Termin, der ausfällt, wird als Event gelöscht oder verschoben — die Serie bleibt davon unberührt.
  • NAMING.md und frontend/static/pedaler.svg liegen bewusst nur lokal.