aza/AzA march 2026/intern_portal/docs/ODT_BROWSER_EDITING_PLAN.md

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).