Inventory/changes.md

Änderungsprotokoll

23. September 2026

PostgreSQL und Docker

• PostgreSQL ist jetzt die Standarddatenbank für Entwicklung und Produktion. Die Anwendung wechselt bei fehlender Konfiguration nicht mehr automatisch zu SQLite.
• Ein separater Docker-Dienst migration stellt die Werkzeuge für Export, Schema-Migration und Datenimport bereit.
• docker-compose.dev.yml ermöglicht den lokalen Betrieb unter http://localhost:8000 ohne HTTPS-Domain. Der Webport ist nur an localhost gebunden.
• Erforderliche PostgreSQL-Variablen werden in Docker Compose auf fehlende Werte geprüft.
• SQLite bleibt ausdrücklich für isolierte Unit-Tests und temporäre Migrationskopien verfügbar.

Übernahme bestehender SQLite-Daten

• scripts/export_sqlite.py erstellt einen konsistenten temporären Snapshot und exportiert dessen Daten. Die Quelldatenbank wird schreibgeschützt geöffnet und bleibt unverändert.
• Vorhandene Exportdateien werden nicht überschrieben.
• Das Kommando import_sqlite_export übernimmt den Export transaktional in eine vorbereitete, leere PostgreSQL-Datenbank. Vorhandene Inventardaten, Benutzer oder Gruppen führen zum Abbruch.
• Die beiden von einer früheren Migration angelegten Standard-Gerätetypen werden als Ausgangsdaten erkannt und innerhalb der Importtransaktion ersetzt.
• Benutzer, Passwort-Hashes, Rollen, API-Schlüssel-Hashes, Geräte, Archivstatus, Zusatzfelder, Einstellungen und Historie werden übernommen. Sitzungen werden nicht übertragen; eine erneute Anmeldung ist erforderlich.
• ID-Sequenzen und die Gerätenummernfolge werden beim Import berücksichtigt. Upload-Dateien müssen separat in das Medienvolume kopiert werden.
• Die vollständigen Befehle stehen im Leitfaden zur PostgreSQL-Migration.

Sicherheit und Datenintegrität

• Gleichzeitige Bearbeitung: Geräte besitzen eine ganzzahlige revision. Browser-Formulare senden expected_revision; veraltete Versionen werden abgewiesen. Die Detailansicht sperrt den Datensatz während der Prüfung und Speicherung innerhalb einer Transaktion.
• API-Kompatibilität: PATCH-Anfragen unterstützen expected_revision. Bestehende Clients können weiterhin expected_updated_at verwenden. Zeitstempel steigen auch bei geringer Auflösung der Systemuhr strikt an.
• Datenbankschema: Migration 0006_device_revision ergänzt das Versionsfeld und passt die Aktualisierung des Zeitstempels an. Bestehende Geräte erhalten zunächst Revision 1.
• Archivierung und Wiederherstellung: Datensatzänderung und Audit-Eintrag erfolgen gemeinsam in einer Transaktion mit Datensatzsperre.
• Bestätigungsdialoge: Mitarbeiternamen und andere Dialogtexte werden als Text eingefügt und nicht mehr als HTML interpretiert.
• Tabellenexporte: XLSX-Textwerte werden ausdrücklich als Textzellen geschrieben. Potenziell als Formeln interpretierte CSV-Textwerte erhalten ein vorangestelltes Apostroph. Numerische Werte bleiben Zahlen.
• Eingabeprüfung: Ungültige numerische Filter, fehlerhafte JSON-Strukturen und ungültige Spalteneinstellungen werden abgefangen. Nicht endliche Dezimalwerte wie NaN und Infinity werden bei der entsprechenden Werteingabe abgewiesen. Ganzzahlfelder akzeptieren keine stillschweigend abgeschnittenen Nachkommastellen mehr.

Bedienung und Konfiguration

• Inline-Auswahllisten für Mitarbeiter und Auswahlwerte sind nicht mehr auf die ersten 15 Einträge beschränkt.
• Die aktuelle Auswahl bleibt im Inline-Editor erhalten, auch wenn sie deaktiviert wurde oder nicht in der Antwort enthalten ist.
• Das Verlassen eines unveränderten Inline-Feldes löst keinen Speichervorgang mehr aus.
• Der Seed-Befehl legt nur fehlende Einträge an. Angepasste Mitarbeiternamen, Statusfarben, Sortierungen und deaktivierte Einträge werden beim Containerstart nicht mehr überschrieben.
• Die geänderten JavaScript-Abschnitte für Bestätigungsdialoge und Inline-Bearbeitung wurden lesbarer strukturiert.

Backup und Wiederherstellung

• Datenbankexport und Komprimierung werden getrennt auf Erfolg geprüft. Ein fehlgeschlagener pg_dump erzeugt keine als erfolgreich gemeldete Sicherung mehr.
• Sicherungen werden zunächst in einem temporären Verzeichnis erstellt, auf gültige Komprimierung geprüft und erst danach als fertige Datei abgelegt.
• Die Backup- und Restore-Skripte führen .env nicht mehr als Shellcode aus. Verbindungswerte werden innerhalb des Datenbankcontainers verwendet.
• Vor einer Wiederherstellung wird das Archiv vollständig entpackt und geprüft. SQL-Fehler brechen die Wiederherstellung innerhalb einer gemeinsamen Transaktion ab.
• Temporäre Dateien werden aufgeräumt; unter POSIX werden restriktive Dateirechte verwendet.
• .gitattributes legt LF-Zeilenenden für Shellskripte fest.

Prüfungen und aktueller Stand

• Python: 53 Tests ausgeführt; 52 erfolgreich, ein PostgreSQL-Sperrtest mangels PostgreSQL-Laufzeit übersprungen. Der zuvor fehlgeschlagene Test zur Erkennung veralteter Änderungen besteht jetzt.
• Frontend: DOM-basierte Regressionstests für sichere Dialogtexte, erhaltene Auswahlwerte, unveränderte Felder und Speicherung mit Versionsprüfung erfolgreich.
• Backup: Vier Prüfungen für erfolgreichen Export/Import, fehlgeschlagenen Datenbankexport, beschädigte Archive und Fehler beim Restore erfolgreich.
• Django: Systemprüfungen erfolgreich; keine fehlenden Modellmigrationen erkannt.
• Konfiguration: YAML-Syntax der Docker-Compose-Dateien und des CI-Workflows geprüft; JavaScript-Syntax geprüft.
• Datenexport: Die vorhandenen SQLite-Daten wurden probeweise exportiert und in ein frisches temporäres SQLite-Schema geladen: 109 Datensätze aus neun Modellen. Die Prüfsumme der ursprünglichen SQLite-Datei blieb unverändert.
• CI vorbereitet: Der neue Workflow führt die Tests mit PostgreSQL 17 sowie die Backup- und Frontend-Prüfungen aus.

Stand der ursprünglichen Vorbereitung: Auf dem Windows-Rechner war Docker nicht installiert. Die folgenden Schritte wurden anschließend auf dem Server durchgeführt; die lokale SQLite-Datenbank blieb dabei unverändert.

26. September 2026 – Wechsel zu Traefik

• Caddy durch Traefik v3.7.13 im Projekt und auf dem Server ersetzt.
• Router und Sicherheitsheader werden über Dateien konfiguriert; kein Docker-Socket und kein öffentliches Dashboard.
• HTTPS-Adresse und Weiterleitungen von Port 80 und 8001 bleiben erhalten. Statische Dateien liefert WhiteNoise aus.
• Die bisherige Stamm-CA wurde übernommen; bereits eingerichtetes Clientvertrauen bleibt gültig.
• Ein systemd-Timer prüft täglich die LAN-Zertifikate. Erneuerungen werden ohne Proxy-Neustart geladen; der CA-Schlüssel bleibt auf dem Host.
• Konfiguration, CA-Zustand und PostgreSQL wurden vor der Umstellung gesichert. Anwendung und Datenbank wurden nicht neu erstellt.
• Vier Zertifikatstests bestanden. HTTPS, Loginseite, CSS, Logo, API-Zugriffsschutz, Weiterleitungen und das Nachladen eines erneuerten Zertifikats wurden geprüft.
• Compose-Dateien, CI und Betriebsdokumentation aktualisiert; Details in docs/traefik.md.

26. September 2026 – Geräteablauf und Aufgaben

• Ein Gerät durchläuft Eingang, Inspektion, gegebenenfalls Reparatur, Lagerung und Ausgabe. Übergänge werden mit Benutzer, Zeit und Notiz protokolliert. Der Bestandsstatus wird bei Reparatur, Lagerung und Ausgabe automatisch abgeglichen.
• Aufgaben haben Status, Fälligkeitsdatum und optionale Zuständigkeit. Offene Aufgaben sperren Lagerung und Ausgabe. Die Aufgabenübersicht zeigt offene und erledigte Arbeiten.
• Eingabe, Detailansicht und Tabellenzeilen zeigen Hardwarefelder passend zum Gerätetyp; ein Drucker hat keine RAM-Eingabe mehr.
• Schema-Migrationen 0007/0008 ergänzen Ablauf und Aufgaben und ordnen bestehende Geräte anhand ihres Status ein. Nicht passende ältere Hardwarewerte bleiben unter custom_values.legacy_hardware erhalten.
• Bestehende Benutzer, Geräte und Nummern bleiben erhalten. Die Hardware-Spalten der Basistabelle bleiben für bestehende Exporte und API-Clients vorhanden; bei unpassenden Typen sind sie leer.

26. September 2026 – Datenbank und Bedienung überarbeitet

• Gemeinsame Gerätedaten und typabhängige Hardwaredaten getrennt. Computer, Bildschirme und Drucker erhalten jeweils eine eigene Spezifikationstabelle. Migration 0009 übernimmt die bisherigen Werte vor dem Entfernen der alten Hardwarespalten. Export, Suche und API verwenden weiter dieselben Feldnamen.
• Zusätzliche Datenbankregeln sichern gültige Ablauf- und Aufgabenstände ab; Indizes beschleunigen häufige Aufgaben- und Verlaufsabfragen (Migration 0010).
• „Ablauf“ ist jetzt direkt über die Hauptnavigation erreichbar. Das Board zeigt Geräte nach Arbeitsschritt und erlaubt neue Aufgaben sowie Übergänge direkt auf der Karte. Tabellenzeilen öffnen die vollständige Geräteseite; dort stehen Aufgaben und Ablauf vor dem Bearbeitungsformular.

26. September 2026 – Eingaben je Arbeitsschritt

• In der Inspektion können Mängel und die zum Gerätetyp passenden technischen Daten direkt auf dem Ablauf-Board erfasst werden. Die Hardwarewerte werden in den bestehenden typbezogenen Spezifikationstabellen gespeichert.

• Für Reparaturen werden die durchgeführten Arbeiten mit Zeit und Bearbeiter als eigene Einträge dokumentiert. Inspektionsbefunde sind ebenso historisiert.

• In der Lagerung kann der Empfänger direkt eingetragen werden. Der vorhandene Empfänger wird wiederverwendet oder neu angelegt; vor der Ausgabe bleibt ein Empfänger verpflichtend.

• Migration 0011 ergänzt die Tabellen inventory_inspectionrecord und inventory_repairrecord. Bestehende Geräte und Ablaufdaten bleiben erhalten.

• Die Ablauf-Übersicht zählt offene Aufgaben aus den bereits geladenen Aufgabendaten. Dadurch entfällt eine teure Aggregation pro Arbeitsschritt.

28. September 2026 – Getrennte Gerätetyp-Tabellen

• Eigene 1:1-Spezifikationstabellen für Laptop, Desktop und AiO ergänzt. Bildschirm/Monitor und Drucker behalten ihre getrennten Tabellen; die allgemeine Computertabelle dient nur noch frei definierten Typen.

• Monitore haben nun Auflösung und Anschlüsse. Drucker haben Anschlüsse, Druckverfahren, Duplex und Farbdruck. Die Computer-Typen haben passende Hardwarefelder einschließlich Anschlüssen.

• Formulare, Inspektions-Board, API, Suche, Filter sowie Excel-Import und -Export verwenden die neuen Felder und Tabellen.

• Migration 0012 überträgt bestehende Laptop-, Desktop- und AiO-Werte. Geräte, Aufgaben, Benutzer und Ablaufhistorien bleiben erhalten.

• Für Datenbankwerkzeuge ist PostgreSQL über 127.0.0.1:15432 auf dem Server und einen SSH-Tunnel erreichbar. Port 15432 ist nicht im LAN offen.

28. September 2026 – Dynamische Geräteformulare

• Bei „Neues Gerät“ erscheinen die passenden technischen Felder unmittelbar nach Auswahl des Gerätetyps. Modell und technische Daten werden auch bei der Mehrfachanlage in den jeweiligen Spezifikationstabellen gespeichert.
• Auf der Geräteseite wechseln die sichtbaren Hardwarefelder ebenfalls sofort beim Typwechsel, ohne Aktualisieren der Seite. Nicht passende Eingaben werden beim Speichern serverseitig ignoriert; bestehende Werte bleiben bei einem Typwechsel in den bisherigen Verlaufsdaten erhalten.
• Übersicht, Geräteliste, Ablauf und Aufgaben aktualisieren sich nach Änderungen in einem anderen offenen Tab automatisch. Beim Zurückkehren in einen älteren Tab werden die Daten ebenfalls neu geladen, solange keine Eingabe bearbeitet wird.
• Das vorhandene CS-R-Logo ist jetzt das Favicon auf allen Seiten, einschließlich Anmeldung und Fehlerseite.
• Ein Hell-/Dunkelmodus-Schalter steht in der Seitenleiste, auf Mobilgeräten in der Kopfzeile und auf der Anmeldeseite bereit. Die Auswahl bleibt im Browser gespeichert; ohne Auswahl gilt die Systemeinstellung.

29. September 2026 – Repository aufgeräumt

• Das alte Projektarchiv wurde in den lokalen, nicht versionierten Ordner backups/ verschoben. Es bleibt als Sicherung erhalten.
• Git- und Docker-Ausschlüsse für lokale Datenbanken, Uploads, Archive, Caches und erzeugte Dateien wurden ergänzt. Quelltexte verwenden in Git einheitliche LF-Zeilenenden.
• Die CI-Konfiguration wurde von GitHub Actions nach Gitea Actions verschoben. Öffentliche Hilfsaktionen werden ausdrücklich von gitea.com geladen, nicht über die GitHub-Standardeinstellung von Gitea.

29. September 2026 – Browserprüfung mit Playwright

• Ein wiederholbarer Playwright-Test prüft die wichtigsten Bedienabläufe in Chromium mit einer kurzlebigen, getrennten Datenbank. Er deckt auch Rollen, Import/Export, Änderungsverlauf, Mobilnavigation und Dunkelmodus ab.
• Nach Anwendung eines Filters schließt sich die Filterfläche wieder. Die aktiven Filter bleiben am Filterknopf sichtbar; Gerätedaten lassen sich sofort anklicken und bearbeiten.
• Geräte können nun direkt auf ihrer Detailseite archiviert werden. Der vorhandene Archivbereich erlaubt anschließend die Wiederherstellung.
• Beim Excel-Import lassen sich jetzt auch Anschlüsse, Auflösung, Druckverfahren, Duplex und Farbdruck zuordnen. Damit können diese typspezifischen Angaben aus einem Export wieder übernommen werden.
• Die Änderungen wurden zusätzlich auf dem Testserver mit PostgreSQL 17 geprüft. Ein Playwright-Lauf über HTTPS sowie alle 66 Django-Tests im Container waren erfolgreich. Angelegte Testdatensätze wurden entfernt.
• deploy/, traefik/ und verschachtelte Python-Caches sind vom Docker- Buildkontext ausgeschlossen; so gelingt der Web-Build auch bei zugriffsbeschränkten Betriebsdateien auf dem Server.