Harlekin
6b2b4c4c8c
Prüfung / Lint, Typen, Tests (push) Canceled after 0s
Prüfung / Images bauen (pdf) (push) Canceled after 0s
Prüfung / Images bauen (web) (push) Canceled after 0s
Prüfung / Images bauen (worker) (push) Canceled after 0s
Images / bauen (pdf, docker/pdf.Dockerfile) (push) Canceled after 0s
Images / bauen (web, docker/web.Dockerfile) (push) Canceled after 0s
Images / bauen (worker, docker/worker.Dockerfile) (push) Canceled after 0s
Bisher liess sich eine einzelne Fallakte und ein einzelnes Dokument als PDF
sichern. Wer den Stand zu einer Person brauchte, rief beides einzeln ab,
legte es von Hand zusammen und wusste danach nicht, ob er alles hatte.
Ein Dossier ist die Personalakte, dahinter alle ihre Dokumente, dahinter
alle Fallakten, in denen die Person vorkommt - jeweils in derselben
Druckdarstellung wie einzeln. Fuer eine Abteilung dasselbe, je Mitglied
getrennt: eine Abteilung hat keine eigenen Fallakten, sie hat Mitglieder,
die in Fallakten vorkommen. Alles in einen Topf geschuettet staende dieselbe
Akte mehrfach da, ohne dass man saehe, ueber wen sie dort steht.
Der Abrufer waehlt die hoechste Stufe, die aufgenommen wird. Das ist keine
Zugriffspruefung, sondern eine Entscheidung ueber den Umfang - und beides
darf nie durcheinandergeraten:
- Was ueber der Freigabestufe des Abrufers liegt, existiert fuer ihn
nicht. Es steht nicht im Abzug, wird nicht gezaehlt und nicht erwaehnt.
- Was er selbst ausgeschlossen hat, steht als Vermerk im PDF, nach Stufe
aufgeschluesselt. Eine gekuerzte Mappe darf nicht wie eine
vollstaendige aussehen, und der Deckel steht zusaetzlich auf jeder
Seite im Wasserzeichen.
Beide Grenzen laufen in der Datenbankabfrage, nicht danach in JavaScript.
Alles wird als eine Druckseite gerendert statt als mehrere
zusammengeheftete PDFs. So laufen Seitenzahlen, Kopfzeile und Wasserzeichen
durch, und es gibt keinen zweiten Weg, der irgendwann anders aussieht als
der erste. Dafuer sind die vorhandenen Druckansichten zu Bausteinen
geworden - CaseSheet und DocumentSheet stehen jetzt in components/print und
werden von den alten Seiten wie vom Dossier benutzt.
Der Zwischenspeicherschluessel traegt den Deckel, sonst bekaeme ein Abruf
bis Stufe 1 die Datei eines Abrufs bis Stufe 4. Und der Stand ist der
spaeteste ueber alle enthaltenen Akten, nicht der der Kopfdaten allein -
sonst gaebe der Zwischenspeicher einen Abzug heraus, in dem ein
inzwischen geaendertes Dokument im alten Wortlaut steht.
Jeder Abruf steht mit seinem Deckel im Protokoll. Ohne den sagt der
Eintrag, dass jemand etwas ausser Haus gegeben hat, aber nicht wie viel.
AfiS-Aktensystem
Fall- und Personalaktenverwaltung für die Abteilung für innere Sicherheit eines SCP-RP-Servers. Anmeldung und Berechtigungen laufen vollständig über Discord.
Interne Anwendung für eine geschlossene Gruppe von zehn bis fünfzig Personen, selbst gehostet. Keine Mandantentrennung, keine öffentliche Registrierung.
Was es kann
- Fallakten mit Kopfdaten, Abschnitten nach Vorlage und einem Verlauf, der nur wächst
- Personalakten, überwiegend für Externe, mit Aktenblatt zum Ausdrucken
- Abteilungen als Ebene darüber: was zu ihnen aktenkundig ist, ergibt sich aus ihren Mitgliedern
- Dokumente nach Vorlage, an einer Fall- oder Personalakte
- Fünfstufige Klassifizierung mit feldgenauer Schwärzung
- Volltextsuche je Freigabestufe, Kommandopalette auf Strg+K
- Chat in jeder Akte, mit Übernahme einer Nachricht als Vermerk
- Export als PDF mit Wasserzeichen, jeder Abruf protokolliert
- Zugriffsprotokoll über jede schreibende Aktion und jeden Lesezugriff ab Stufe 3
Zusicherungen
Acht Regeln, die im Code und wo möglich in der Datenbank durchgesetzt sind. Sie sind der Grund, warum das System so gebaut ist, wie es gebaut ist - Codekommentare verweisen unter ihrer Nummer hierher.
- Berechtigungsprüfung immer serverseitig und immer in der Datenbankabfrage. Niemals alle Datensätze laden und danach filtern.
- Verlaufseinträge dürfen nachträglich geändert werden, aber niemals unsichtbar. Jede
Änderung erzeugt eine Version, jede Zurücknahme lässt einen Grabstein stehen, beides ist
für alle sichtbar, die den Eintrag sehen dürfen. Es gibt kein
DELETE- das steht als Regel in der Datenbank, nicht nur in der Anwendung. - Jede schreibende Aktion und jeder Lesezugriff ab Stufe 3 erzeugt einen Protokolleintrag.
- Keine Dateiendungen als Typprüfung. Immer Magic Bytes. Kein SVG, kein HTML, keine Archive.
- Keine Blockade-Spinner. Jede Ansicht hat ein Skelett, jede Änderung eine sofortige Rückmeldung.
- Existenz ist auch eine Information. Akten oberhalb der Sichtstufe tauchen weder in Listen noch in Trefferzahlen noch in Rückverweisen auf. Kein Zugriff heisst 404, nicht 403.
- Keine Geheimnisse im Repository. Alles über
.env, Vorlage in.env.example. - Keine Einmal-Container. Der Betrieb läuft über Dockge, das beendete Container nicht
dauerhaft anzeigt. Migrationen gehören ins Startkommando von
web, wiederkehrende Aufgaben in Dauerläufer mit eigenem Cron. Jeder Dienst braucht einen Healthcheck, weil das in Dockge die Statusanzeige ist.
Aufbau
web/ Next.js 15, App Router, React 19
worker/ discord.js, gleicht Rollen und Mitgliedschaft ab
pdf/ Playwright, erzeugt die PDF-Ausdrucke
packages/db/ Prisma-Schema, Migrationen, Seed
docker/ Dockerfiles für web, worker und pdf
compose.yaml Der Dockge-Stack
.env.example Vorlage für den .env-Reiter in Dockge
Stack: Next.js 15 mit React 19 und TypeScript, Auth.js v5 mit Discord-Provider, Prisma auf PostgreSQL 16, Tailwind ohne Komponentenbibliothek. ClamAV und Playwright laufen als eigene Container.
Einrichten
Discord-Application anlegen, Bot auf den Server einladen und Server Members Intent aktivieren - ohne das liefert der Bot keine Rollen.
Lokal entwickeln
Node 22 und pnpm 9.
corepack enable && pnpm install
docker run -d --name afis-db -e POSTGRES_DB=afis -e POSTGRES_USER=afis \
-e POSTGRES_PASSWORD=afis -p 5434:5432 postgres:16-alpine
cp .env.example .env
# DATABASE_URL und DIRECT_DATABASE_URL auf localhost:5434 zeigen lassen
pnpm --filter @afis/db run build # erzeugt den Prisma-Client
pnpm db:deploy && pnpm db:seed
pnpm dev
Prüfen wie die CI:
pnpm lint && pnpm typecheck && pnpm test
pnpm test:e2e
pnpm test legt sich eine eigene Datenbank afis_test an und lässt die
Entwicklungsdatenbank in Ruhe: Verlaufseinträge und Protokollzeilen sind nach Regel 2 nicht
löschbar, was ein Test dort anlegt, bliebe für immer stehen.
Betrieb
Gehostet als ein Dockge-Stack. Die .env wird nicht im Repository gepflegt, sondern im
.env-Reiter von Dockge.
| Verwaltung | Dockge, ein Stack namens afis unter /opt/stacks/afis/ |
| Erreichbarkeit | Cloudflare Tunnel, kein offener Port am Router |
| Aktualisieren | Dockge → Stack → Update, Migration läuft automatisch mit |
| Backup | zwei Dauerläufer mit Cron: nächtlicher Dump plus restic offsite |
| Wiederherstellung | scripts/restore-test.sh spielt einen Dump in eine Wegwerf-Datenbank und vergleicht Zeilenzahlen, Regeln und Trigger |