Unnötige Datein gelöscht. DB normalisiert

README.md

@@ -5,7 +5,7 @@ Dieses Projekt ist eine lokale Single-Page-Webanwendung zur Verwaltung elektrote
 
 - einem Frontend in `Test.html`, `styles.css` und den JS-Modulen unter `public/js/`
 - einem einfachen Node.js-Server in `server.js`
-- einem Datenspeicher in CSV-Dateien unter `sessions/`
+- einem Datenspeicher in einer SQLite-Datenbank (`node:sqlite`) unter `sessions/projektuebersicht.db`
 - einem Docker-Setup unter `Docker/`
 
 ## Datei- und Komponentenübersicht
@@ -17,9 +17,10 @@ Dieses Projekt ist eine lokale Single-Page-Webanwendung zur Verwaltung elektrote
   - stellt statische Dateien (`Test.html`, die Module unter `js/`, `styles.css`, etc.) bereit
   - implementiert Endpunkte:
     - `GET /` → liefert `Test.html`
-    - `GET /load-all` → lädt alle CSV-Dateien aus dem aktiven `sessions/<DEPARTMENT>/`-Ordner inkl. `_people.csv`
-    - `POST /save-csv` → speichert eine CSV-Datei (Dateiname wird validiert)
-    - `POST /delete-csv` → löscht eine CSV-Datei
+    - `GET /load-all?department=…` → lädt alle Sitzungen plus globale Personenliste einer Abteilung
+    - `POST /save-week {department, week}` → speichert/aktualisiert eine Sitzung
+    - `POST /save-people {department, people}` → ersetzt die globale Personenliste einer Abteilung
+    - `POST /delete-week {department, label}` → löscht eine Sitzung
     - `GET /health` → Gesundheitscheck
   - legt das `sessions`-Verzeichnis beim Start an, falls es nicht existiert
   - beendet sich mit aussagekräftiger Fehlermeldung, wenn der Port belegt ist
@@ -33,16 +34,15 @@ Dieses Projekt ist eine lokale Single-Page-Webanwendung zur Verwaltung elektrote
 
 - `public/js/` (Module)
   - Die Client-Logik ist in kleine klassische Script-Dateien aufgeteilt (alle Funktionen global auf `window`):
-    `globals.js`, `utils.js`, `ui.js`, `date-picker.js`, `csv.js`, `server.js`, `store.js`, `weeks.js`,
+    `globals.js`, `utils.js`, `ui.js`, `date-picker.js`, `server.js`, `store.js`, `weeks.js`,
     `board.js`, `people.js`, `projects.js`, `load.js`, `gantt.js`, `showmode.js`, `tabs-auth.js`, `pdf.js`,
     `init.js` sowie die Plan-Module unter `js/plan/` (`plan-state`, `plan-build-gantt`, `plan-gantt`,
     `plan-drag`, `plan-modals`, `plan-schedule`).
   - rendert das Projektboard, die Projekt- und Personenverwaltung sowie die Auslastungsansicht
-  - lädt Daten über den Server und speichert Änderungen zurück als CSV
+  - lädt Daten über den Server und speichert Änderungen als JSON-Objekte in die SQLite-Datenbank zurück
   - verwendet `currentDepartment` zur Trennung von Abteilungen (`ELT`, `HLS`, `ARCH`)
   - speichert:
-    - `sessions/<DEPT>/<WEEK>.csv`
-    - `sessions/<DEPT>/_people.csv` (globale Personenliste pro Abteilung)
+    - alle Sitzungen und die globale Personenliste pro Abteilung in `sessions/projektuebersicht.db`
   - sortiert Sitzungen nach Kalenderwoche, nicht alphabetisch
   - sperrt historische Sitzungen automatisch (bis auf die chronologisch letzte)
   - Personen sind global pro Abteilung verwaltet; historische Sitzungen behalten ihre lokalen Personenkopien
@@ -91,27 +91,18 @@ Dieses Projekt ist eine lokale Single-Page-Webanwendung zur Verwaltung elektrote
 ## Speicherorte und Datenfluss
 
 ### Speicherung
-- Alle persistierten Daten werden als CSV-Dateien in `sessions/` gespeichert.
-- Innerhalb von `sessions/` existieren Abteilungsordner:
-  - `sessions/ELT/`
-  - `sessions/HLS/`
-  - `sessions/ARCH/`
-- Jede Abteilung enthält mindestens:
-  - `_people.csv` → globale Personenliste mit Rollen und vollständigem Namen
-  - `KW_XX___YYYY.csv` oder vergleichbare Sitzungsdateien → Sitzungsdaten mit Projekten, Zuordnungen und Anwesenheit
+- Alle persistierten Daten werden in einer SQLite-Datenbank (`node:sqlite`, `DatabaseSync`, WAL-Modus) unter `sessions/projektuebersicht.db` gespeichert.
+- Innerhalb von `sessions/` liegen ausschließlich die SQLite-Datenbankdateien (`projektuebersicht.db` + WAL/SHM).
 
 ### Wo wird der Server erstellt?
 - Der Server wird in `server.js` erstellt.
 - `server.js` startet einen Express-Server auf Port `3003` oder dem Wert von `process.env.PORT`.
 - Das Frontend ruft diesen Server über `window.location.origin` an.
 
-### Wo werden die Dateien gespeichert?
-- Das Frontend schreibt über den Server in das Dateisystem.
-- In `js/store.js` ruft die Anwendung beim Speichern `/save-csv` auf.
-- Der Server legt CSV-Dateien unter `sessions/<DEPARTMENT>/` ab.
-- Beispiel:
-  - `sessions/ELT/KW_32___2026.csv`
-  - `sessions/ELT/_people.csv`
+### Wo werden die Daten gespeichert?
+- Das Frontend schreibt über den Server in die SQLite-Datenbank.
+- In `js/store.js` ruft die Anwendung beim Speichern `/save-week` (Sitzungen) bzw. `/save-people` (globale Personen) auf.
+- Der Server schreibt die relationalen Tabellen in `sessions/projektuebersicht.db` (eine Transaktion pro Sitzung, siehe `serializeWeek()`/`loadWeeks()` in `server.js`).
 
 ## Betrieb
 
@@ -141,8 +132,8 @@ http://localhost:3003
 ```
 
 ## Wichtige Hinweise
-- Der Server benötigt Lese-/Schreibzugriff auf `sessions/`.
+- Der Server benötigt Lese-/Schreibzugriff auf `sessions/` (für die SQLite-Datenbank und das Docker-Bind-Mount).
 - Die Docker-Compose-Konfiguration mountet `./sessions` in den Container. Achte darauf, dass der relative Pfad im Kontext korrekt ist, wenn du `docker compose` aus einem anderen Verzeichnis startest.
-- `js/store.js` und `js/server.js` arbeiten mit Abteilungsparametern und speichern Daten abteilungsweise in separaten Unterordnern.
+- `js/store.js` und `js/server.js` arbeiten mit Abteilungsparametern und speichern Daten abteilungsweise getrennt.
 - Die Passwortfunktion ist nur ein einfacher Client-Mechanismus im Frontend und kein echter Sicherheitsmechanismus.
-- Globale Personen werden in `_people.csv` verwaltet. Wird eine Person global gelöscht, bleibt sie in bereits existierenden Sitzungen sichtbar.
+- Globale Personen werden pro Abteilung in der Datenbank verwaltet. Wird eine Person global gelöscht, bleibt sie in bereits existierenden Sitzungen sichtbar (Wochen-Personenkopien).