Files
management/docs/issues/0045-report-event-kein-kontaktweg-fuer-melder.md
T

81 lines
3.5 KiB
Markdown
Raw Normal View History

---
type: issue
id: "0045"
status: done
created: 2026-08-11
milestone: M1
priority: low
area: element
related: []
---
# Inhalts-Meldung führt ins Leere: kein Kontaktweg für Melder
## Problem / Motivation
Der Web-Client kann Inhalte melden (`report_event`), aber
`report_event.admin_message_md` ist in `element-values.yaml` **nicht gesetzt**
(Stand 2026-08-11 gegen die Live-Config geprüft). Wer etwas meldet, sieht danach
keinen Kontaktweg — keine Angabe, an wen die Meldung geht oder wo man nachfassen
kann. Für einen Community-Betrieb mit Moderation (Draupnir) ist das eine offene
Kante: Melden funktioniert technisch, führt für den Nutzer aber ins Leere.
## Acceptance
- `report_event.admin_message_md` in
`apps/production/custom-configs/element-values.yaml` gesetzt, mit einem echten
Kontakt-/Meldeweg (Moderationsraum oder Kontaktadresse).
- Live sichtbar: nach einer Meldung erscheint der hinterlegte Hinweis.
## Notes
Braucht **eine Angabe von sorb**: welcher Raum bzw. Kontakt der Meldeweg sein
soll. Danach ist es eine Zeile Config. Bewusst nicht auf `waiting` gesetzt, weil
noch nicht begonnen — der fehlende Input ist im Text benannt.
## Erledigt 2026-08-15
`report_event.admin_message_md` gesetzt (gitops `83a14e1`). Der Melder sieht nach dem
Absenden jetzt, dass die Meldung angekommen ist — **und an wen er sich wenden kann**:
> Deine Meldung ist bei der Serveradministration eingegangen und wird gesichtet.
> Für Rückfragen oder wenn es dringend ist, schreib bitte direkt an `@sorb:axion1337.chat`.
### Zustellweg: Weg B (Entscheidung sorb)
Zur Debatte stand, den Weg über **Draupnir** abzubilden (`pollReports`). Geprüft und
**verworfen**: Draupnir liest Meldungen über die **Synapse-Admin-API** und müsste dafür
**Server-Admin** werden — gemessen ist `@draupnir:axion1337.chat` heute `admin = 0`. sorb:
*„ich mache keine Bots zum vollwertigen Admin."* Server-Admin hieße volle Admin-API
(Nutzer deaktivieren, Räume löschen); ein kompromittierter Bot wäre ein kompromittierter
Homeserver.
**Stattdessen Weg B:** Meldungen bleiben im `event_reports`-Speicher und werden über das
bereits laufende **Element Admin** gesichtet. Deshalb benennt der Text **einen Menschen**
statt einen Automatismus zu versprechen — `@sorb` ist der einzige Server-Admin und damit
der Einzige, der die Meldungen überhaupt sehen kann.
### Kontext für die Einordnung
- **Bislang gab es 0 Meldungen** (`select count(*) from event_reports`). Der Melde-Knopf
existierte, wurde nie benutzt, und es wäre niemandem aufgefallen.
- Für Missbrauchsmeldungen wäre ein öffentlicher Raum ohnehin falsch gewesen — es gibt
außer `#onboarding` (9 Mitglieder) und Testräumen keinen Raum, und eine Meldung gehört
nicht vor Publikum.
### Verifiziert (live, nicht nur committet)
| Prüfung | Ergebnis |
|---|---|
| JSON weiterhin gültig | `config.json` parst |
| ConfigMap im Cluster | enthält `admin_message_md` |
| Rollout ausgelöst | Chart-Hash-Label wechselte nach **~70 s**, neuer Pod |
| Öffentlich ausgeliefert | `https://axion1337.chat/config.json` enthält den Text |
**Nebenbefund:** Der Rollout bestätigt die Analyse aus #0044 empirisch — die
Chart-Hash-Labels lösen den Neustart bei Config-Änderung selbstständig aus, innerhalb eines
HelmRelease-Intervalls (1 min). Kein Handgriff nötig, kein Reloader.
⚠️ **Bleibt bewusst offen:** Weg B heißt, dass jemand **aktiv** in Element Admin nachsehen
muss — es gibt keinen Alarm bei einer neuen Meldung. Bei 0 Meldungen bisher vertretbar;
sollte sich das ändern, ist das der nächste Punkt.