Kurz im README: was die Anwendung kann, auf einen Blick. Lang in docs/funktionen.md: jeder Typ mit seinen Grenzen, dazu Landingpages, Dateien, Feedback, Rechte, Single Sign-on, Domains und Betrieb — samt der Frage, warum manches so entschieden ist. docs/roadmap.md haelt fest, was in welcher Reihenfolge gebaut wurde, und sammelt Vorschlaege fuer danach. Bewusst als Vorschlaege mit grober Aufwandsschaetzung, nicht als Zusage: was zuerst kommt, entscheidet, was im Betrieb fehlt.
153 lines
5.7 KiB
Markdown
153 lines
5.7 KiB
Markdown
# Roadmap
|
|
|
|
Was gebaut ist, und was danach sinnvoll wäre. Der zweite Teil ist eine
|
|
Sammlung von Vorschlägen mit einer groben Einschätzung des Aufwands — keine
|
|
Zusage und keine Reihenfolge. Was zuerst kommt, entscheidet, was im Betrieb
|
|
fehlt.
|
|
|
|
---
|
|
|
|
## Gebaut
|
|
|
|
### Version 1 — Grundgerüst (13.08.2026)
|
|
|
|
- Next.js-Anwendung und PostgreSQL als Docker-Compose-Stack, ohne Reverse
|
|
Proxy, Migrationen beim Start
|
|
- QR-Typ-Registry als Dispatch-Tabelle — ein neuer Typ ist ein Modul plus ein
|
|
Formular, ohne Eingriff in den übrigen Code
|
|
- Typ **Website**, statisch und dynamisch, mit Kurz-URL, 302-Weiterleitung und
|
|
Scan-Zähler
|
|
- Gestaltung: Farben mit Kontrastwarnung, Größe, Fehlerkorrektur, Rand
|
|
- Download als PNG und SVG, serverseitig gerendert
|
|
- „Meine Codes“ mit Ziel ändern und Löschen
|
|
- Deutsche Oberfläche, deutsche Fehlermeldungen, Validierung mit Zod
|
|
- Update-Skript für Linux/macOS und Windows
|
|
|
|
### Typen einzeln freigeben (14.08.2026)
|
|
|
|
Ausblenden nicht gebrauchter Typen in der Verwaltung. Bereits erstellte Codes
|
|
eines abgeschalteten Typs funktionieren weiter.
|
|
|
|
### Phase A — acht weitere Typen (14.08.2026)
|
|
|
|
vCard, App-Link, WhatsApp, E-Mail, SMS, Standort, Zahlung (GiroCode und
|
|
Zahlungslink), WLAN.
|
|
|
|
### Phase B1 — Anmeldung, Gruppen, Rollen (14.08.2026)
|
|
|
|
Abschaltbare Anmeldung, Benutzerverwaltung, Gruppen mit den Rollen
|
|
Administrator, Bearbeiter und Betrachter, Sitzungen in der Datenbank,
|
|
scrypt-Passwörter, Sperre nach Fehlversuchen.
|
|
|
|
### Phase B2 — mehrere Domains (14.08.2026)
|
|
|
|
Domains für Kurz-URLs, den Gruppen zugeteilt. Slug je Domain eindeutig,
|
|
Host-Header gegen die registrierten Domains geprüft.
|
|
|
|
### Listenansicht (14.08.2026)
|
|
|
|
„Meine Codes“ als Liste mit Suche, Sortierung und Gruppenfilter — gedacht für
|
|
viele Projekte nebeneinander. Karten bleiben als zweite Ansicht.
|
|
|
|
### Phase C — die letzten sechs Typen (14.08.2026)
|
|
|
|
Mehrere Links, Social Media, Video, PDF, Bild, Feedback. Dazu:
|
|
|
|
- Landingpages als eigene Gattung (`/s/{slug}`), ohne App-Navigation
|
|
- Datei-Upload mit Inhaltsprüfung, Größengrenze und Aufräumen
|
|
- Feedback mit anonymer Erhebung und Auswertung
|
|
|
|
Damit sind **alle 15 vorgesehenen Typen** gebaut.
|
|
|
|
### Single Sign-on (15.08.2026)
|
|
|
|
Anmeldung über Authentik und andere OIDC-Anbieter, mit PKCE und geprüftem
|
|
ID-Token.
|
|
|
|
### Dokumentation (15.08.2026)
|
|
|
|
Bedienungsanleitung mit Bildern, Authentik-Anleitung, Funktionsübersicht.
|
|
Die Bilder erzeugt ein Skript, damit sie nicht veralten.
|
|
|
|
---
|
|
|
|
## Denkbar als Nächstes
|
|
|
|
Die Einschätzungen sind grobe Hausnummern für eine Person, die den Code kennt.
|
|
|
|
### Naheliegend
|
|
|
|
**Statistik über die Zeit** · mittel
|
|
Der Zähler weiß heute nur, wie oft und wann zuletzt. Ein Verlauf je Tag wäre
|
|
eine eigene Tabelle plus ein Diagramm in der Codeansicht. Die eigentliche
|
|
Frage ist nicht die Technik, sondern wie lange man so etwas aufbewahrt — und
|
|
was man dabei über die Scannenden erfährt. Ein reiner Tageszähler ohne
|
|
Herkunft und Gerät ist unbedenklich und würde für „läuft die Kampagne?“
|
|
genügen.
|
|
|
|
**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.
|
|
|
|
**Papierkorb statt Löschen** · klein
|
|
Gelöschte Codes 30 Tage aufheben, dann endgültig entfernen. Heute ist ein
|
|
gedruckter Code nach einem Fehlklick unwiederbringlich tot.
|
|
|
|
**Codes duplizieren** · klein
|
|
„Wie dieser, aber mit anderem Ziel“ — bei vielen ähnlichen Projekten spart
|
|
das jedes Mal ein paar Minuten.
|
|
|
|
### Wenn der Bedarf da ist
|
|
|
|
**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.
|
|
|
|
**Logo im QR-Code** · mittel
|
|
Ein kleines Bild in die Mitte setzen, mit erzwungener Fehlerkorrektur H und
|
|
einer Warnung, wenn zu viel verdeckt wird. Braucht eine ehrliche Prüfung mit
|
|
mehreren Scanner-Apps, sonst entstehen Codes, die nur auf dem eigenen Handy
|
|
funktionieren.
|
|
|
|
**Ablaufdatum und Zeitsteuerung** · mittel
|
|
Ein Code, der ab einem Datum woandershin führt oder abläuft — für
|
|
Veranstaltungen und Aktionen.
|
|
|
|
**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.
|
|
|
|
### Größere Brocken
|
|
|
|
**Mehrsprachige Oberfläche** · groß
|
|
Die Anwendung ist durchgehend deutsch, auch in den Fehlermeldungen und den
|
|
Landingpages. Eine zweite Sprache berührt jede Datei.
|
|
|
|
**Eigene Gestaltung der Landingpages** · groß
|
|
Logo, Farben und Schrift je Gruppe, damit die Seite nach der eigenen Firma
|
|
aussieht. Technisch überschaubar, gestalterisch eine eigene Aufgabe — und es
|
|
braucht Grenzen, damit nichts Unlesbares entsteht.
|
|
|
|
**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.
|
|
|
|
---
|
|
|
|
## 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“.
|