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](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.