Initialize clean CSR inventory repository

changes.md

@@ -0,0 +1,175 @@
+# Ä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](docs/postgresql-migration.md).
+
+### 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.
+
+### Serverinstallation auf 192.168.188.45
+
+- Das Projekt wurde unter `/home/denis/csr-inventory` mit PostgreSQL, Gunicorn und Caddy installiert.
+- Alle **53 Tests bestanden auf PostgreSQL**, einschließlich des zuvor lokal übersprungenen Sperrtests. Die Django-Produktionsprüfung meldete keine Beanstandungen.
+- Die 109 Datensätze der lokalen Projektdatenbank wurden übernommen, darunter zwei Geräte und die vorhandenen Benutzerkonten.
+- Die bisher laufende andere Inventarsoftware wurde nach Sicherung von Datenbank, Konfiguration und Uploads entfernt. Ihre Volumes und Quelldateien bleiben für eine mögliche Wiederherstellung erhalten.
+- Die neue Anwendung ist unter **https://192.168.188.45/** erreichbar. Port 8001 leitet auf HTTPS weiter.
+- Eine LAN-Konfiguration für Caddy ergänzt lokale Zertifikate und den Zugriff per IP-Adresse. Das öffentliche Stammzertifikat liegt unter `docs/homelab-root-ca.crt`; es wurde nicht automatisch in den Windows-Zertifikatsspeicher importiert.
+- Tägliche Datenbank-Backups um 02:00 Uhr Berliner Zeit wurden über einen systemd-Timer eingerichtet. Eine Sicherung wurde erfolgreich in einer separaten Prüfdatenbank wiederhergestellt.
+- HTTPS, Healthcheck, Loginseite, statische Dateien, API-Zugriffsschutz und die Weiterleitung wurden geprüft. Andere Anwendungen auf dem Server laufen unverändert weiter.
+- Zugriff, Zertifikatsinstallation und Wartung sind in [docs/serverbetrieb.md](docs/serverbetrieb.md) beschrieben.
+
+## 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](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.
+
+- Auf Server 192.168.188.45 nach PostgreSQL-Sicherung migriert und ausgerollt.
+  Alle 58 Tests bestanden mit PostgreSQL; 2 Geräte und 4 Konten blieben erhalten.
+
+## 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.