Lars
6c7c24e887
All checks were successful
Deploy Development / deploy (push) Successful in 48s
Test Suite / pytest-backend (push) Successful in 45s
Test Suite / lint-backend (push) Successful in 1s
Test Suite / build-frontend (push) Successful in 15s
Test Suite / k6 /health Baseline (push) Successful in 34s
Test Suite / playwright-tests (push) Successful in 1m35s
Document cross-app architecture patterns, Mitai alignment, and family entitlement standards. Documentation only; no runtime changes. Co-authored-by: Cursor <cursoragent@cursor.com>
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)
|