---
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.