Florian Wilde
586e1f042f
Bisher liess sich der laufenden Anwendung nicht ansehen, welche Fassung sie ist. Nach einem Update war damit auch nicht zu erkennen, ob es angekommen ist — die haeufigste Frage im Betrieb. Die Fussleiste nennt jetzt die Version und fuehrt auf /version mit dem vollstaendigen Verlauf. Zusammengetragen ist er aus dem, was es schon gab: dem Abschnitt „Gebaut" der Roadmap und der Git-Historie. Gepflegt wird der Verlauf an genau einer Stelle, src/lib/changelog.ts. Daraus entsteht sowohl die Seite als auch die CHANGELOG.md (npm run changelog); eine Pruefung mit --check wacht darueber, dass beides zusammenpasst. Zwei gepflegte Listen liefen unweigerlich auseinander, und ein Changelog, der nicht stimmt, ist schlimmer als keiner. Die Historie hatte keine Tags. Die Eintraege sind deshalb nach Erscheinungstag zu Versionen zusammengefasst — die Nummern sind nachtraeglich vergeben, die Daten stammen aus den Commits. Zu jeder Version gibt es jetzt einen annotierten Tag im Repo; v1.6.0 folgt beim Merge. Die Roadmap fuehrt den Verlauf nicht mehr doppelt, sondern verweist darauf und behaelt den Blick nach vorn. Refs #9
165 lines
6.9 KiB
Markdown
165 lines
6.9 KiB
Markdown
# Roadmap
|
|
|
|
Was gebaut ist, was als Nächstes kommt und was danach denkbar wäre. Die
|
|
Aufwände sind grobe Einschätzungen, keine Zusagen.
|
|
|
|
---
|
|
|
|
## Gebaut
|
|
|
|
Der vollständige Verlauf mit Versionsnummern steht im
|
|
[Changelog](../CHANGELOG.md) — und in der Anwendung selbst unter
|
|
**Version und Änderungen**, erreichbar über die Versionsnummer in der
|
|
Fußzeile.
|
|
|
|
Kurz gefasst: Version 1.0.0 (13.08.2026) brachte das Grundgerüst mit dem Typ
|
|
Website, 1.1.0 alle fünfzehn Typen samt Anmeldung, Gruppen und Domains,
|
|
1.2.0 Single Sign-on und die Sicherheitsdurchsicht, 1.3.0 Erscheinungsbild
|
|
und Dark Mode, 1.4.0 sprechende Kurz-Links, 1.5.0 benennbare statische Codes
|
|
und 1.6.0 diesen Versionshinweis.
|
|
|
|
---
|
|
|
|
## Als Nächstes
|
|
|
|
In dieser Reihenfolge. Die Einschätzungen sind grobe Hausnummern für eine
|
|
Person, die den Code kennt.
|
|
|
|
### 1. QR-Typen je Gruppe freigeben · mittel
|
|
|
|
Heute gilt die Freigabe eines Typs für die ganze Installation: Was
|
|
abgeschaltet ist, ist für alle weg. Bei mehreren Gruppen ist das zu grob — die
|
|
Marketingabteilung braucht Social Media, die Werkstatt nur Website und PDF.
|
|
|
|
Geplant: Die Freigabe bekommt eine zweite Dimension. Es bleibt eine globale
|
|
Einstellung als Grundlage, und je Gruppe lässt sich davon abweichen. Wer in
|
|
mehreren Gruppen ist, sieht auf der Startseite die Vereinigung; beim Anlegen
|
|
entscheidet die gewählte Gruppe.
|
|
|
|
Zu klären ist der Fall, in dem ein Typ global aus, in einer Gruppe aber an
|
|
ist — entweder die Gruppe darf das überstimmen, oder die globale Abschaltung
|
|
gewinnt immer. Die zweite Lesart ist die weniger überraschende und
|
|
wahrscheinlich die richtige.
|
|
|
|
Berührt: `QrTypeSetting` (zusammengesetzter Schlüssel aus Typ und Gruppe),
|
|
`src/lib/qr/availability.ts`, die Startseite und die Typ-Verwaltung, die dann
|
|
eine Gruppenauswahl bekommt.
|
|
|
|
### 2. Statistik über die Zeit · mittel
|
|
|
|
Der Zähler weiß heute nur, wie oft und wann zuletzt. Gebraucht wird der
|
|
Verlauf: Wie lief die Kampagne in den ersten Tagen, wann ist Ruhe
|
|
eingekehrt?
|
|
|
|
Geplant: eine Tabelle mit einer Zeile je Code und Tag, dazu ein Diagramm in
|
|
der Codeansicht und die Zahlen der letzten 7, 30 und 365 Tage.
|
|
|
|
Bewusst **ohne** Herkunft, Gerät oder Verweisseite. Ein reiner Tageszähler
|
|
sagt nichts über einzelne Menschen aus und braucht deshalb weder Einwilligung
|
|
noch Löschfristen. Wer mehr will, muss sich mit beidem befassen — das ist eine
|
|
andere Entscheidung als „ein Diagramm wäre schön“.
|
|
|
|
### 3. Papierkorb statt Löschen · klein
|
|
|
|
Heute ist ein gedruckter Code nach einem Fehlklick unwiederbringlich tot,
|
|
samt seiner Dateien und Rückmeldungen.
|
|
|
|
Geplant: Gelöschte Codes 30 Tage aufheben und dann endgültig entfernen. In
|
|
„Meine Codes“ ein Reiter „Papierkorb“ mit Wiederherstellen. Solange ein Code
|
|
im Papierkorb liegt, bleibt sein Slug belegt — sonst könnte ihn ein neuer Code
|
|
bekommen und die gedruckten Codes zeigten plötzlich woandershin.
|
|
|
|
### 4. Logo im QR-Code · mittel
|
|
|
|
Ein kleines Bild in die Mitte setzen, wie man es von Firmen-Codes kennt.
|
|
|
|
Geplant: Upload eines Logos je Code, mittig eingesetzt, mit erzwungener
|
|
Fehlerkorrektur **H** und einer Warnung, sobald zu viel Fläche verdeckt wird.
|
|
|
|
Das ist der Punkt mit dem größten Risiko, etwas Kaputtes auszuliefern: Ein
|
|
Code, der auf dem eigenen Handy noch funktioniert, kann bei anderen
|
|
Scanner-Apps durchfallen. Gehört deshalb nicht ohne eine ehrliche Prüfung mit
|
|
mehreren Geräten und Apps ausgeliefert — und mit einer klaren Obergrenze für
|
|
die verdeckte Fläche.
|
|
|
|
### 5. Ablaufdatum und Zeitsteuerung · mittel
|
|
|
|
Ein Code, der ab einem Datum woandershin führt oder abläuft — für
|
|
Veranstaltungen, Aktionen und Aushänge mit Verfallsdatum.
|
|
|
|
Geplant, in zwei Stufen:
|
|
|
|
- **Ablauf:** ab einem Zeitpunkt zeigt der Code eine erklärende Seite statt
|
|
des Ziels. Wichtig ist der Text — wer davorsteht, soll erfahren, dass die
|
|
Aktion vorbei ist, nicht dass „etwas nicht gefunden“ wurde.
|
|
- **Zeitplan:** mehrere Ziele mit Gültigkeitsfenstern, damit derselbe
|
|
Aufsteller montags auf die Mittagskarte und samstags auf die Veranstaltung
|
|
zeigt.
|
|
|
|
Zu bedenken: Zeitzonen und die Frage, was beim Bearbeiten mit vergangenen
|
|
Fenstern geschieht.
|
|
|
|
---
|
|
|
|
## Später denkbar
|
|
|
|
**Das Fenster der Ersteinrichtung schließen** · klein
|
|
Heute wird das erste Konto ohne jede Legitimation angelegt und ist gleich
|
|
Administrator. Wer die Anwendung öffentlich stellt, bevor er sein Konto
|
|
angelegt hat, kann sie an einen Fremden verlieren. Vorschlag: ein einmaliges
|
|
Token, das beim ersten Start ins Protokoll geschrieben wird und für die
|
|
Ersteinrichtung nötig ist. Klein im Aufwand — und das Erste, was zu tun ist,
|
|
falls die Anwendung je aus dem eigenen Netz herausgeht. Siehe
|
|
[sicherheit.md](sicherheit.md).
|
|
|
|
**Codes exportieren** · klein
|
|
Eine CSV aller Codes einer Gruppe mit Name, Kurz-URL, Ziel und Scans — für
|
|
die Übergabe an eine Druckerei oder die Ablage.
|
|
|
|
**Codes duplizieren** · klein
|
|
„Wie dieser, aber mit anderem Ziel“ — bei vielen ähnlichen Projekten spart
|
|
das jedes Mal ein paar Minuten.
|
|
|
|
**Stapelverarbeitung** · mittel
|
|
Eine CSV hochladen und daraus 200 Codes erzeugen, als ZIP zurück. Sinnvoll,
|
|
sobald jedes Produkt oder jeder Tisch einen eigenen Code bekommt.
|
|
|
|
**Gruppen aus dem Verzeichnis übernehmen** · mittel
|
|
Die OIDC-Anbindung übernimmt heute bewusst nur die Identität. Eine Zuordnung
|
|
von Verzeichnisgruppen zu Gruppen dieser Anwendung ist möglich, braucht aber
|
|
eine klare Regel dafür, was mit von Hand vergebenen Rollen geschieht — sonst
|
|
verliert jemand beim nächsten Anmelden stillschweigend seine Rechte.
|
|
|
|
**Passwortgeschützte Landingpages** · mittel
|
|
Für Unterlagen, die nicht jeder sehen soll, der den Aushang fotografiert.
|
|
Heute ist die Empfehlung klar: Vertrauliches gehört nicht hinter einen
|
|
offenen QR-Code.
|
|
|
|
**Dateien außerhalb der Datenbank** · mittel
|
|
Heute liegen Uploads in PostgreSQL, damit es bei einem Volumen bleibt. Wer
|
|
sehr viele oder sehr große Dateien ablegt, will sie irgendwann auf einem
|
|
Objektspeicher (S3) haben. Der Wechsel betrifft nur `src/lib/uploads.ts` und
|
|
die Auslieferungsroute — aber auch die Sicherungsstrategie.
|
|
|
|
**Erscheinungsbild je Gruppe** · groß
|
|
Seit dem 16.08. lassen sich Name, Logo, Favicon und Farbe für die ganze
|
|
Installation einstellen. Der nächste Schritt wäre, das je Gruppe zu erlauben
|
|
und die Landingpages mit dem Logo der jeweiligen Gruppe zu versehen — damit
|
|
eine gescannte Seite nach der Firma aussieht, der sie gehört. Technisch
|
|
überschaubar, gestalterisch eine eigene Aufgabe; es braucht Grenzen, damit
|
|
nichts Unlesbares entsteht.
|
|
|
|
**Mehrsprachige Oberfläche** · groß
|
|
Die Anwendung ist durchgehend deutsch, auch in den Fehlermeldungen und den
|
|
Landingpages. Eine zweite Sprache berührt jede Datei.
|
|
|
|
---
|
|
|
|
## Wie ein neuer Typ dazukommt
|
|
|
|
Falls doch noch einer fehlt: Er besteht aus einem Modul in
|
|
`src/lib/qr/types/`, einer Formular-Komponente, je einem Registry-Eintrag und
|
|
— wenn er eine eigene Seite braucht — einer Landingpage. Am übrigen Code
|
|
ändert sich nichts. Näheres im [README](../README.md), Abschnitt „Einen
|
|
weiteren Typ ergänzen“.
|