118 lines
3.9 KiB
Markdown
118 lines
3.9 KiB
Markdown
|
# 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
|
|||
|
|
|
|||
|
|
1. **Separate Compliance-Queue-App** — Inbox-Reuse ist bewusst.
|
|||
|
|
2. **Legal Hold durch Club-Admin** — Superadmin-only.
|
|||
|
|
3. **Meldungen ohne Statusworkflow/Archiv** — Wiedereröffnen muss möglich sein.
|
|||
|
|
4. **Fehlende Verknüpfung Medien-Lifecycle** — Hold muss Purge blockieren.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Verwandte Dokumentation
|
|||
|
|
|
|||
|
|
- [MEDIA_ASSETS_DESIGN_PRINCIPLES.md](./MEDIA_ASSETS_DESIGN_PRINCIPLES.md)
|
|||
|
|
- [ACCESS_LAYER_DESIGN_PRINCIPLES.md](./ACCESS_LAYER_DESIGN_PRINCIPLES.md)
|
|||
|
|
- [DESIGN_PRINCIPLES_INDEX.md](./DESIGN_PRINCIPLES_INDEX.md)
|