Files
management/docs/issues/0045-report-event-kein-kontaktweg-fuer-melder.md
Thore CimbalandClaude Opus 4.8 ae92952f7e docs(issues): close #0045 — reporting no longer ends in silence
Route B per sorb: Draupnir would have needed server admin to poll reports, and
bots do not get that. So reports stay in event_reports for review through Element
Admin, and the message names a person rather than promising an automatism —
@sorb being the only admin who can see them at all.

Verified live rather than assumed: the config parses, the ConfigMap carries it,
the chart hash label flipped after about 70 seconds and rolled a new pod, and the
public config.json serves the text. That rollout also confirms the #0044 analysis
empirically — no reloader needed.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-15 12:00:00 +00:00

3.5 KiB

type, id, status, created, milestone, priority, area, related
type id status created milestone priority area related
issue 0045 done 2026-08-11 M1 low element

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.