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
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:
1754501300legt für jeden Fahrer mit Event einen Teilnehmer an und entfernt danachriders.eventundriders.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.- Bestehende Events werden auf
timing = trueundparticipation = geschlossengesetzt. 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
updateRuleder users-Collection schließtsuperadminvom 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.tsund 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.mdundfrontend/static/pedaler.svgliegen bewusst nur lokal.