Matrix-Benachrichtigungen pro Ereignis einzeln aktivierbar/deaktivierbar machen #6

Closed
opened 2026-08-15 09:24:19 +00:00 by AxonByteDev · 0 comments
Owner

Problem

Aktuell gibt es nur eine globale Matrix-Konfiguration (Homeserver/User/Passwort/Raum) — sobald Matrix eingerichtet ist, werden für alle Ereignisse automatisch Benachrichtigungen verschickt, ohne dass man das einzeln steuern kann. Konkret z. B.: Nach jedem abgeschlossenen Server-Update kommt eine Erfolgs-/Fehler-Nachricht auf Matrix — das soll gezielt an-/abschaltbar sein.

Aktuell vorhandene Benachrichtigungs-Ereignisse (Codeanalyse)

  • backend/scheduler.py: geplanter Scan hat neue Updates gefunden ("🔔 Updates verfügbar").
  • backend/routers/updates.py: Update abgeschlossen — Erfolg bzw. Fehlschlag (zwei Stellen: Bot-/auto_confirm-Modus und interaktiver Modus).
  • backend/self_update.py: Ergebnis eines PatchPilot-Selbst-Updates.

Technischer Vorschlag

  • Neue Settings-Keys analog zum bestehenden Muster (_DEFAULT_SETTINGS in backend/database.py, z. B. wie update_auto_apply), z. B.:
    • notify_scan_available (Default "true")
    • notify_update_result (Default "true")
    • notify_self_update (Default "true")
  • In backend/notifications.py an jedem send(...)-Aufruf vorher den passenden Setting-Wert prüfen (oder ein kleiner Wrapper notifications.send_if(setting_key, message), der das intern erledigt) — Default "true" erhält das bisherige Verhalten, niemand verliert ungefragt Benachrichtigungen.
  • Frontend (Settings.tsx): drei Checkboxen im Matrix-Bereich, gebunden nach demselben Muster wie der vorhandene scan_enabled-Toggle (Zeile ~684 ff., settingsMut.mutate({ key: 'true'/'false' })).
## Problem Aktuell gibt es nur eine globale Matrix-Konfiguration (Homeserver/User/Passwort/Raum) — sobald Matrix eingerichtet ist, werden für alle Ereignisse automatisch Benachrichtigungen verschickt, ohne dass man das einzeln steuern kann. Konkret z. B.: Nach jedem abgeschlossenen Server-Update kommt eine Erfolgs-/Fehler-Nachricht auf Matrix — das soll gezielt an-/abschaltbar sein. ## Aktuell vorhandene Benachrichtigungs-Ereignisse (Codeanalyse) - `backend/scheduler.py`: geplanter Scan hat neue Updates gefunden ("🔔 Updates verfügbar"). - `backend/routers/updates.py`: Update abgeschlossen — Erfolg bzw. Fehlschlag (zwei Stellen: Bot-/auto_confirm-Modus und interaktiver Modus). - `backend/self_update.py`: Ergebnis eines PatchPilot-Selbst-Updates. ## Technischer Vorschlag - Neue Settings-Keys analog zum bestehenden Muster (`_DEFAULT_SETTINGS` in `backend/database.py`, z. B. wie `update_auto_apply`), z. B.: - `notify_scan_available` (Default `"true"`) - `notify_update_result` (Default `"true"`) - `notify_self_update` (Default `"true"`) - In `backend/notifications.py` an jedem `send(...)`-Aufruf vorher den passenden Setting-Wert prüfen (oder ein kleiner Wrapper `notifications.send_if(setting_key, message)`, der das intern erledigt) — Default `"true"` erhält das bisherige Verhalten, niemand verliert ungefragt Benachrichtigungen. - Frontend (`Settings.tsx`): drei Checkboxen im Matrix-Bereich, gebunden nach demselben Muster wie der vorhandene `scan_enabled`-Toggle (Zeile ~684 ff., `settingsMut.mutate({ key: 'true'/'false' })`).
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
AxonByteDev/PatchPilot#6
No description provided.