93 lines
3.9 KiB
Markdown
93 lines
3.9 KiB
Markdown
|
# 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`).
|