# Changelog – Server-Bibliothek

Entwicklungshistorie in der Reihenfolge, wie das Projekt entstanden ist.
Dient als Kontext für die Übergabe: welche Entscheidung wurde warum
getroffen, welches Problem hat welche Änderung ausgelöst.

## v1 – Erster Prototyp
Ausgangslage: Software-Installer und Dokumentation lagen verstreut, keine
Übersicht, wer welche Software auf welchem Rechner hat. Ziel: ein Ort für
alles.
- Flask-Webanwendung + SQLite-Datenbank (eine Datei, kein DB-Server)
- Software-Katalog: Name, Kategorie, Version, Installer-Pfad, Silent-Install-
  Parameter, Freitext-Dokumentation
- Status-Anzeige pro Tool: Aktuell / Bitte prüfen / Nie geprüft (Schwelle:
  30 Tage seit letzter Prüfung) – löst das Kernproblem "Installer-Ordner
  4 Wochen nicht gepflegt, muss alles neu heruntergeladen werden"
- Einfache Zuweisungs-Tabelle (ein Eintrag pro Mitarbeiter+Tool)
- Design bewusst zurückhaltend gehalten (kein Frontend-Framework), damit die
  Zielperson (keine Programmiererfahrung) es per Doppelklick starten kann

## v2 – Bedienbarkeit für Nicht-Entwickler
Auslöser: "Ich dachte, ich kann das Tool direkt installieren – ist Python
nicht nur zum Programmieren da?"
- `install.bat` / `start.bat`: kein Terminal/Befehle mehr nötig, nur
  Doppelklick
- Python-Versionsprüfung mit klarer Fehlermeldung statt kryptischem Absturz

## v3 – Automatische Aktualisierung
Auslöser: Wunsch, dass sich Standard-Software selbst aktuell hält, ohne
Verteilung an andere Rechner (das war zu diesem Zeitpunkt explizit
NICHT gewünscht).
- Drei Update-Quellen: winget (Windows-Paketverwaltung), GitHub-Releases,
  fester Download-Link
- Sicherheitskopie der alten Datei vor jedem Ersetzen
- Update-Protokoll pro Tool
- Mini-Doku-Box im Formular, die je nach gewählter Quelle live erklärt, wo
  man den passenden Wert findet (ersetzt einen langen Erklärtext)

## v4 – Mehrfach-Zuweisung statt Einzel-Protokollierung
Auslöser: "Wenn ich mehrere Tools gleichzeitig zuweise, will ich nicht für
jede Software einzeln ein Formular ausfüllen."
- Checkliste mit "Alle auswählen", ein Formular erzeugt mehrere
  Zuweisungen auf einmal

## v5 – Protokolle statt flacher Zuweisungsliste
Auslöser: "Bei 40 Mitarbeitern × 40 Tools wird die Liste unübersichtlich."
- Neues Datenmodell: `protokolle` (1 Eintrag pro Rechner-Einrichtung) +
  `zuweisungen` (n Tools pro Protokoll)
- Download-Button pro Tool (lokale Datei oder externer Link)

## v6 – Ordner-Organisation und Bugfixes (mehrere Anläufe)
Auslöser: reale Nutzung zeigte, dass Installer-Dateien "nackt" im
gemeinsamen Ablageordner landeten, weil mehrere Tools denselben Basis-Ordner
eingetragen hatten.
- Mehrere Iterationen, bis die Lösung wirklich robust war:
  1. Automatische Ordner-Erstellung beim Speichern
  2. Automatische Dateinamens-Vergabe (aus Tool-Namen abgeleitet)
  3. **Endgültige Lösung:** `effektiver_ablageordner()` erzwingt IMMER einen
     Tool-eigenen Unterordner, unabhängig davon, was im Feld eingetragen ist
     – auch rückwirkend, ohne bestehende Einträge ändern zu müssen
- Bugfix: Wurde eine Installer-Datei manuell gelöscht, meldete das System
  fälschlich "bereits aktuell" (nur Versionsnummer wurde verglichen, nicht
  ob die Datei noch existiert) – behoben durch zusätzliche Existenzprüfung
- Download-Button erkennt jetzt automatisch Ordner vs. Einzeldatei und
  bietet bei Ordnern den Inhalt als ZIP an (wichtig für portable Tools wie
  Blender)
- Versions-Anzeige in der Seitenleiste ergänzt (Diagnose-Hilfe, ob wirklich
  die neueste Version läuft – nötig geworden, weil mehrfach der Verdacht
  aufkam, ein Fix "greife nicht", obwohl der laufende Prozess nur nicht neu
  gestartet worden war)

## v7 – Dokumentations-Bilder
- Upload/Anzeige/Löschen von Screenshots direkt auf der Tool-Detailseite

## v8 – Verteilung ("Rechner einrichten")
Auslöser: Rückbesinnung, dass eine Verteilungsfunktion doch gebraucht wird –
allerdings ohne Remote-Zugriff auf fremde Rechner (das wurde bewusst
verworfen: zu hoher Aufwand/Risiko ohne vorhandene Domänen-Infrastruktur).
Stattdessen: Skript, das man AUF dem neuen Zielrechner selbst ausführt.
- Route `/einrichten`: Checkliste aller Tools, erzeugt bei Bedarf ein
  individuelles Installations-Paket (kein Pflegeaufwand für 100+ feste
  Skripte)
- Generiertes PowerShell-Skript: lädt jedes ausgewählte Tool herunter,
  installiert es still, meldet danach automatisch ein Protokoll an den
  Server zurück (Rechnername wird automatisch erkannt)
- Tools ohne Installer-Datei (portable/entpackte Tools wie Blender) werden
  als ZIP bereitgestellt – zunächst automatisch entpackt, nach Rückmeldung
  ("das will ich selbst entscheiden können") bewusst NICHT mehr automatisch
  entpackt, sondern nur bereitgestellt
- Fester Client-Ordner `C:\ClientBibliothek` auf dem Zielrechner statt
  verstreuter Temp-Pfade – ermöglicht eine einzelne Antivirus-/Defender-
  Ausnahme statt vieler Einzelpfade; wird vom Skript beim ersten Lauf
  automatisch selbst eingetragen (`Add-MpPreference`)
- Firewall-Freigabe-Skript ergänzt, nachdem der Test im echten
  Firmennetzwerk anstand (Port 5000 war durch die Windows-Firewall blockiert)

## Testmethodik (durchgehend)
Da die Zielumgebung Windows ist, die Entwicklung aber in einer Linux-Umgebung
stattfand, wurde wo immer möglich zusätzlich abgesichert:
- PowerShell 7 wurde in der Entwicklungsumgebung nachinstalliert, um
  generierte Skripte mit dem echten Parser auf Syntaxfehler zu prüfen
- Netzwerk-Operationen (Download, Formular-Rückmeldung, ZIP-Erstellung/
  -Entpacken) wurden, wo plattformunabhängig möglich, live gegen den
  laufenden Server ausgeführt statt nur angenommen
- Windows-exklusive Teile (Admin-Rechte-Anfrage, `msiexec`, `winget`,
  Defender-Cmdlets) blieben auf Syntaxprüfung + Dokumentations-Abgleich
  beschränkt – siehe `ARCHITEKTUR.md`, Abschnitt 7, für Details