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

ONLYOFFICE Docs – Document Server, gute ODT-Unterstützung, Callback-API zum Speichern.
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

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

3.9 KiB Raw Permalink Blame History Unescape Escape