# ODT-Browser-Bearbeitung – Plan Phase 1.2 (AZA Intern)

Stand: Vorbereitung ohne produktiven Editor-Dienst.

## Warum ein separater Editor-Dienst nötig ist

ODT ist ein OpenDocument-Format (ZIP mit XML). Browser können ODT nicht nativ wie ein Textfeld bearbeiten. Für WYSIWYG-Bearbeitung im Browser braucht es einen **Office-Editor-Dienst**, der:

- die Datei lädt und rendert,
- Bearbeitung im Browser ermöglicht,
- Änderungen zurück an das Portal speichert.

AZA Intern speichert Dateien derzeit als statische Uploads mit UUID-Namen. Echte Inline-Bearbeitung erfordert eine **getrennte Integrationsschicht** zwischen Portal und Editor.

## Zielarchitektur (getrennt vom produktiven AZA-System)

| Komponente | Pfad / Rolle |
|---|---|
| AZA Intern Portal | `/root/aza-intern-portal` – FastAPI, SQLite, Uploads |
| Office-Editor (später) | `/root/aza-intern-office` – ONLYOFFICE Docs **oder** Collabora Online |
| **Nicht** anfassen | `/root/aza-app`, Empfang, Chat, KI-Budget, Stripe, WooCommerce |

- Keine gemeinsame Datenbank mit dem produktiven System.
- Kein Caddy-Reload ohne separaten, geprüften Publish-Block für `intern.aza-medwork.ch` (+ ggf. Editor-Subdomain).
- Editor nur im Intern-Netzwerk / hinter Reverse-Proxy erreichbar.

## Empfohlene Editor-Optionen

1. **ONLYOFFICE Docs** – Document Server, gute ODT-Unterstützung, Callback-API zum Speichern.
2. **Collabora Online** – WOPI-Protokoll, Open-Source-Alternative.

Entscheidung erst nach lokaler Evaluation (Ressourcen, Lizenz, Wartung).

## Grobe Implementierungsschritte (später)

### a) Editor getrennt evaluieren

- ONLYOFFICE/Collabora lokal in Docker testen (eigener Compose unter `/root/aza-intern-office`).
- Kein Einbinden in `/root/aza-app`.

### b) Temporäre Datei-URL / Token für Editor

- Portal erzeugt **kurzlebigen Token** (z. B. 5–15 Min.) für eine Datei-ID.
- Editor lädt Datei über signierte URL: `GET /api/files/{id}/editor-fetch?token=…`
- Token: einmalig, an User-Session gebunden, nur für ODT.

### c) Save-Callback zurück ins Portal

- Editor ruft nach Speichern Portal-Endpoint auf: `POST /api/files/{id}/editor-save`
- Portal validiert Token/Signatur, schreibt neue Version in `uploads/` (UUID-Dateiname oder Versionssuffix).
- Metadaten in `files` aktualisieren (`updated_at`, optional `version`).

### d) Versionierung / Backup vor Überschreiben

- Vor jedem Save: Kopie der alten Datei nach `backups/file_versions/`.
- Optional Tabelle `file_versions` (file_id, stored_filename, saved_by, saved_at).

### e) Audit-Log

- Tabelle `file_edit_log`: file_id, user_id, action (open/save), timestamp, IP optional.
- Anzeige im Admin-Bereich oder pro Datei.

## UI-Stand Phase 1.2 (aktuell)

- ODT-Upload erlaubt (Ablage, Drag-and-Drop, Aufgaben).
- Button **«Im Browser bearbeiten»** → `/files/{id}/edit` (Platzhalterseite).
- Kein externer Editor installiert.

## Risiken

| Risiko | Massnahme |
|---|---|
| Dateisperren bei gleichzeitiger Bearbeitung | Editor-Lock / «Wird bearbeitet von …» |
| Save-Callback fehlgeschlagen | Retry, Fehler an User, alte Version behalten |
| Reverse Proxy / CORS | Editor- und Portal-Origin explizit konfigurieren |
| Sicherheit (Token-Leak) | Kurzlebige Tokens, HTTPS, kein öffentlicher Editor ohne Login-Kette |
| Speicher überschreiben ohne Backup | Versionierung vor jedem Save |
| Ressourcen auf Hetzner | Editor-Container separat dimensionieren |

## Was in diesem Schritt bewusst fehlt

- Keine ONLYOFFICE-/Collabora-Installation
- Keine Docker-Container für Office-Editor
- Keine Caddy-Änderungen
- Kein Server-Deploy
- Keine Verbindung zu `/root/aza-app`

## Nächster sinnvoller Schritt

1. ONLYOFFICE Document Server lokal unter `intern_portal/docker/` **nur als Entwurf** evaluieren (optional, separates Ticket).
2. API-Entwurf für `editor-fetch` / `editor-save` in `app.py` als Kommentar oder Stub-Routen (403 «not implemented»).
3. Nach DNS/Caddy für `intern.aza-medwork.ch`: Editor-Subdomain planen (z. B. `office.intern.aza-medwork.ch`).