projektuebersicht/README.md

# Projektübersicht — README

## Übersicht
Dieses Projekt ist eine lokale Single-Page-Webanwendung zur Verwaltung elektrotechnischer Projekte und Sitzungsübersichten. Die Anwendung besteht aus:

- 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 einer SQLite-Datenbank (`node:sqlite`) unter `sessions/projektuebersicht.db`
- einem Docker-Setup unter `Docker/`

## Datei- und Komponentenübersicht

### Wichtige Laufzeit-Dateien
- `server.js`
  - Node.js/Express-Server
  - dient als API für das Frontend
  - stellt statische Dateien (`Test.html`, die Module unter `js/`, `styles.css`, etc.) bereit
  - implementiert Endpunkte:
    - `GET /` → liefert `Test.html`
    - `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

- `package.json`
  - definiert den Node.js-Startbefehl `npm start`
  - enthält Produktionsabhängigkeiten `express` und `cors`

- `package-lock.json`
  - wird für reproduzierbare Docker-Builds verwendet (`npm ci`)

- `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`, `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 als JSON-Objekte in die SQLite-Datenbank zurück
  - verwendet `currentDepartment` zur Trennung von Abteilungen (`ELT`, `HLS`, `ARCH`)
  - speichert:
    - 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

- `Test.html`
  - die Benutzeroberfläche der Anwendung
  - lädt `styles.css` und die JS-Module aus `js/` in fester Reihenfolge (siehe `AGENTS.md`)
  - enthält die Abteilungsauswahl, Sitzungsnavigation, Tab-Navigation und das Passwort-Modal

- `project-plan.html`
  - die Planungsansicht (GANTT/TODOs/Meilensteine) pro Projekt
  - öffnet sich in einem neuen Tab über `openProjectPlan()` (`js/gantt.js`)
  - lädt nur die gemeinsamen Helfermodule plus `js/plan/*`

- `styles.css`
  - Layout und Styling der Oberfläche

### Docker-bezogene Dateien
- `Docker/Dockerfile`
  - Basis-Image: `node:20-alpine`
  - kopiert `package.json` und `package-lock.json`, installiert Produktionsabhängigkeiten mit `npm ci`
  - kopiert den Rest des Projekts in `/app`
  - legt sicherheitshalber `/app/sessions` an
  - läuft als nicht-root-User `node`
  - enthält einen `HEALTHCHECK` auf `/health`
  - startet `node server.js`

- `docker-compose.yml`
  - definiert den Service `projektuebersicht`
  - baut das Image aus dem Projektstamm mit `Docker/Dockerfile`
  - mappt Port `3003:3003`
  - bindet das Host-Verzeichnis `./sessions` in den Container nach `/app/sessions`
  - setzt `restart: unless-stopped`
  - definiert einen `healthcheck`

- `.dockerignore`
  - schließt unnötige Dateien aus dem Docker-Build aus: `Docker/`, `node_modules/`, `npm-debug.log`, `.git`, `.gitignore`

### Sonstige Dateien
- `dein_bild.ico`
  - optionales Icon, wird vom Server statisch ausgeliefert, wenn angefragt

- `AGENTS.md`
  - Projektnotizen / Dokumentation, aber nicht Teil des Anwendungslaufs

## Speicherorte und Datenfluss

### Speicherung
- 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 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

### Lokal mit Node.js
```bash
npm install
npm start
```
Danach ist die Anwendung erreichbar unter `http://localhost:3003`.

Falls der Port belegt ist:
```bash
PORT=3004 npm start
```

### Mit Docker
Im Projektstamm ausführen:

```bash
docker compose -f Docker/docker-compose.yml up --build
```

Danach ist die Anwendung erreichbar unter:

```
http://localhost:3003
```

## Wichtige Hinweise
- 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 getrennt.
- Die Passwortfunktion ist nur ein einfacher Client-Mechanismus im Frontend und kein echter Sicherheitsmechanismus.
- Globale Personen werden pro Abteilung in der Datenbank verwaltet. Wird eine Person global gelöscht, bleibt sie in bereits existierenden Sitzungen sichtbar (Wochen-Personenkopien).