Lars
0e2b938fbd
Some checks failed
Test Suite / lint-backend (push) Waiting to run
Test Suite / build-frontend (push) Waiting to run
Test Suite / k6 /health Baseline (push) Waiting to run
Test Suite / playwright-tests (push) Waiting to run
Deploy Development / deploy (push) Failing after 0s
Test Suite / pytest-backend (push) Has been cancelled
Co-authored-by: Cursor <cursoragent@cursor.com>
3.9 KiB
3.9 KiB
Content Reports (P-13) – Designprinzipien (Extraktion)
Status: Analyse / Arbeitspapier
Stand: 2026-07-04
Geltungsbereich: Modul „Content Reports“ — Meldeverfahren, Posteingang, Legal Hold
Serie: Designprinzipien für Produktfamilie · Shinkan Dokument 10 von 15
Mitai-Vergleich: — (Compliance-spezifisch)
Kernkomponenten:
| Bereich | Pfade |
|---|---|
| API | backend/routers/content_reports.py |
| Legal Hold | backend/media_legal_hold.py |
| Inbox-Integration | GET /api/me/inbox/content-reports |
| Frontend | InboxPage.jsx |
| Migration | 052, 053 |
Modul
Content Reports & Compliance (P-13)
Meldeverfahren für problematische Inhalte (Medien, Übungen), Admin-Posteingang mit Statusworkflow, Priorisierung sensibler Gründe, Anbindung Legal Hold und Medien-Audit.
Designprinzipien
1. Eine Tabelle, ein Workflow — keine separate Admin-Queue
| Prinzip | content_reports + bestehende Inbox-UI für Änderungsanfragen und Meldungen. |
| Begründung | Admin-Arbeit an einem Ort; weniger Navigations-Fragmentierung. |
| Quelle | content_reports.py Docstring |
| Tragfähigkeit | hoch |
| Einschränkung | Zwei Vorgangstypen in einer UI — klare Typ-Kennzeichnung nötig. |
2. Melden optional ohne Auth (eingeschränkt)
| Prinzip | Anonym/offline Meldung für official-Medien erlaubt; sonst Auth empfohlen. |
| Begründung | DSA-Anforderungen; öffentliche Plattform-Inhalte meldbar. |
| Quelle | Router-Berechtigungen |
| Tragfähigkeit | mittel |
| Einschränkung | Missbrauchsschutz (Rate Limit) prüfen. |
3. Priorität bei sensiblen Gründen
| Prinzip | minors, illegal_content, youth_protection → HIGH_PRIORITY automatisch. |
| Begründung | SLA und Admin-Aufmerksamkeit fachlich korrekt. |
| Quelle | HIGH_PRIORITY_REASONS |
| Tragfähigkeit | hoch |
| Einschränkung | — |
4. Rollengetrennte Sicht (Plattform vs. Verein)
| Prinzip | Plattform-Admin: alle; Club-Admin: nur Vereinsmedien-Meldungen. |
| Begründung | Mandanten-Grenze auch im Compliance-Kontext. |
| Quelle | Router-Listenfilter |
| Tragfähigkeit | hoch |
| Einschränkung | — |
5. Legal Hold nur Superadmin aus Meldung
| Prinzip | Mapping report_reason → legal_hold reason_code; set_legal_hold superadmin-geschützt. |
| Begründung | Hochrisiko-Aktion; Anschluss P-11. |
| Quelle | _REASON_TO_HOLD_CODE; media_legal_hold.py |
| Tragfähigkeit | hoch |
| Einschränkung | — |
6. Audit-Spur bei Medien-Meldungen
| Prinzip | media_asset_audit_log Event content_report_filed bei media_asset-Bezug. |
| Begründung | Lifecycle-Entscheidungen nachvollziehbar. |
| Quelle | Migration 053; write_audit_log_entry |
| Tragfähigkeit | hoch |
| Einschränkung | — |
7. E-Mail best-effort, kein Hard-Fail
| Prinzip | Bestätigung an Melder + Admin-Benachrichtigung; SMTP-Fehler blockieren Speichern nicht. |
| Begründung | Meldung geht nicht verloren wenn Mail down. |
| Quelle | Router-Implementierung |
| Tragfähigkeit | mittel |
| Einschränkung | Admins müssen Posteingang auch ohne Mail prüfen. |
Nicht übernehmen
- Separate Compliance-Queue-App — Inbox-Reuse ist bewusst.
- Legal Hold durch Club-Admin — Superadmin-only.
- Meldungen ohne Statusworkflow/Archiv — Wiedereröffnen muss möglich sein.
- Fehlende Verknüpfung Medien-Lifecycle — Hold muss Purge blockieren.