Neben "Drucken" steht am Lauf "Als PDF", im Archiv an jedem Treffer "Protokoll als PDF" — dasselbe Blatt als fertige Datei, zum Verschicken oder Abheften. Unten darauf jetzt zwei Unterschriftsfelder mit Zeile fuer Ort, Datum und Namen; wo eine Vier-Augen-Freigabe erteilt wurde, steht sie mit im Kopf. Erzeugt wird es, indem der Server seine eigene Druckansicht ueber 127.0.0.1 laedt und druckt — mit dem Sitzungscookie des Anfragenden. Damit gibt es genau eine Vorlage fuer Papier und Datei, und fuer das PDF gilt dieselbe Rechte- und Mandantenpruefung wie fuer die Seite. Ein zweites Layout waere billiger und wuerde frueher oder spaeter abweichen, ohne dass es jemandem auffaellt. Ein eigener Browser-Kontext je PDF, kein geteilter: er traegt die fremde Sitzung, und ein geteilter gaebe sie an das naechste PDF weiter. Gespeichert wird nichts — ein abgelegtes PDF waere eine zweite Wahrheit neben dem Lauf. Ein erzeugtes Passwort steht auch hier nie darauf, geprueft am extrahierten Text des fertigen PDF und nicht an den Bytes: der Inhalt ist komprimiert, dort nichts zu finden bewiese nichts. Chromium bleibt optional, und die gemessene Zahl ist der Grund: das Laufzeitbild waechst von 370 MB auf 1,52 GB, Alpines chromium kostet allein 1,13 GB. Er kommt nur mit `--build-arg MIT_PDF=1` beziehungsweise `deploy/install.sh --mit-pdf` mit. Fehlt er, erscheint der Knopf gar nicht erst — ein Knopf, der zuverlaessig in eine Fehlermeldung fuehrt, ist schlimmer als keiner. Ein direkter Aufruf bekommt 503 mit einer Meldung, die sagt, was fehlt und wo es steht; ein leeres PDF gibt es in keinem Fall. Meine Schaetzung lag um das Dreieinhalbfache daneben: "+328 MB" war das .apk-Paket, nicht das Bild, und stand schon im Dockerfile-Kommentar, bevor ich gebaut hatte. Jetzt steht die gemessene Zahl an drei Stellen. 1545 Vitest-Tests (vorher 1526): 15 in tests/pdf.test.ts, die den Handler echt fahren, 3 in tests/pdf-grenze.test.ts fuer die Obergrenze mit gestelltem Browser, einer in tests/archiv.test.ts. Dazu drei E2E-Ablaeufe; volle Suite gruen mit 118 bestanden. Ein Blatt wurde wirklich erzeugt und angesehen. Sechs Gegenproben, alle angeschlagen — darunter ein echtes Passwort auf dem Blatt und die Freigabe des Zaehlers aus dem finally genommen, der Fall, in dem ein Fehlschlag die PDF-Erzeugung bis zum Neustart leise stilllegt. Closes #41 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Laufzettel — Anleitung
Laufzettel ist eine Checkliste für wiederkehrende IT-Arbeiten. Ein Redakteur schreibt einmal auf, was bei einer PC-Neuinstallation, einem Onboarding oder einem Patchday zu tun ist — das ist eine Vorlage. Aus einer veröffentlichten Vorlage entsteht ein Lauf: die Abschrift für einen bestimmten Fall, mit einem bestimmten Gerät und einer bestimmten Person. Den Lauf arbeitet ein Techniker Schritt für Schritt ab, oft am Handy, direkt am Gerät. Am Ende wird er abgeschlossen und archiviert und ändert sich nie wieder.
Auf jedem Gerät klebt ein QR-Aufkleber. Wer ihn scannt, landet auf der Geräteseite und sieht, was dort zu tun ist und was dort schon getan wurde. Der Code auf dem Aufkleber wird nie geändert und nie an ein zweites Gerät vergeben — er ist die einzige Angabe am Gerät, die Jahre hält.
Wer welches Kapitel braucht
Techniker — du arbeitest Läufe ab, scannst Aufkleber und druckst Etiketten:
- 01 Erste Schritte — anmelden, wo was steht
- 02 Läufe abarbeiten — der Alltag, am Schreibtisch und am Handy
- 03 QR-Aufkleber und Tags — scannen, registrieren, Etiketten drucken
- 08 Fehlerbehebung — wenn etwas klemmt
Administrator oder Redakteur — du richtest ein und pflegst:
- 04 Vorlagen bauen — Abschnitte, Schritte, Variablen, veröffentlichen
- 05 Mitarbeiter, Abteilungen und Geräte — Stammdaten und CSV-Import
- 06 Verzeichnis anbinden — Active Directory als Quelle der Personen
- 07 Verwaltung — Benutzer, Rollen, Einstellungen, Betriebsmodus, Kunden
Mitarbeiter — du bedienst Laufzettel nicht, sondern willst nur wissen, was mit deinem Gerät passiert ist:
- 09 Meine Geräte — anmelden, was dort steht und was nicht
Dieses eine Kapitel ist an Mitarbeiter gerichtet und nicht an die IT. Wer die Selbstauskunft im Haus freigibt, kann es weitergeben, ohne den Rest der Anleitung mitzuschicken.
Zwei Betriebsmodi
Laufzettel läuft in einem von zwei Modi. Der Modus entscheidet, ob es eine Kundenebene gibt, und ändert einige Beschriftungen.
| Modus | Für wen | Kundenebene |
|---|---|---|
| Intern | eine Firma und ihre eigenen Mitarbeiter | unsichtbar |
| Dienstleistung | IT-Dienstleister mit mehreren Kunden | sichtbar: Kundenliste, Kundenwahl, Kürzel auf dem Etikett |
Im Modus Intern heißt der Menüpunkt „Mitarbeiter & Geräte“, im Modus Dienstleistung „Personen & Geräte“; dort kommt außerdem „Kunden“ dazu, und das Verzeichnis fällt weg. Wo diese Anleitung „Person“ schreibt, heißt es im Modus Intern auch „Mitarbeiter“ — gemeint ist dasselbe. Umgestellt wird der Modus unter Admin, siehe Kapitel 07.
Drei Zusagen, die überall gelten
- Eine veröffentlichte Version wird nie verändert. Sonst zeigte ein alter Lauf Schritte, die es damals nicht gab. „Bearbeiten“ erzeugt stattdessen eine Kopie als Entwurf.
- Ein archivierter Lauf ist schreibgeschützt. Kein Haken, keine Notiz, kein Kommentar geht danach noch. Nur ein Administrator holt ihn zurück.
- Gelöscht wird fast nichts. Geräte, Abteilungen, Vorlagen und Kunden werden archiviert, Personen nur deaktiviert. Ein archivierter Lauf muss auch in zehn Jahren noch sagen können, für wen er lief.
