Files

T

PTah 117390cbca docs: add 2026-05-29 todo for SAC notifications and Settings UI

Co-authored-by: Cursor <cursoragent@cursor.com>

2026-05-28 15:39:21 +10:00

5.4 KiB

Raw Blame History

ToDo — 29.05.2026 (оповещения SAC + «Настройки»)

Контекст: при UseSAC=exclusive на агентах Telegram/email с хоста не идут — оператору нужны оповещения из SAC. Аналитика и прочее — отдельно (analytics-backlog.md).

Уже есть в коде (не путать с «ещё не сделано»)

Что	Где	Ограничение
Telegram из SAC	`backend/app/services/telegram_notify.py`	Только если в `sac-api.env`: `TELEGRAM_ENABLED=true`, токен, chat_id
Порог severity	`telegram_min_severity` (по умолчанию `high`)	События `info` (успешный RDP `rdp.login.success`) не уходят в TG, пока порог не снизить до `warning`
Вызов при ingest	`events.py` → `notify_event` / `notify_problem`	Шаблон короткий («🚨 SAC событие»), не как у агента
UI «Настройки»	—	Нет — только env-файл на сервере
Email / webhook	TZ F-NOT-01	Не реализованы в backend

Вывод на завтра: для exclusive нужно (1) включить и настроить TG на сервере SAC или (2) сделать раздел «Настройки» в UI + хранение каналов; порог warning и выше для событий и problems.

Замечание по коду: notify_problem() сейчас не проверяет telegram_min_severity (в отличие от notify_event) — исправить в рамках notif-03.

Задачи (приоритет)

P0 — exclusive + Telegram

ID	Задача	Критерий
`notif-01`	Зафиксировать в `agent-integration.md` / runbook: при exclusive канал оповещений = SAC; рекомендуемый `TELEGRAM_MIN_SEVERITY=warning` (или `high` только для prod-шума)	Документ + пример `sac-api.env`
`notif-02`	Проверить на staging: ingest `rdp.login.failed` (warning) → TG; `rdp.login.success` (info) → нет TG при `min=warning`	Чеклист в E2E
`notif-03`	`notify_problem`: учитывать `telegram_min_severity`; опционально отдельный порог для problems	Unit-тест

P1 — UI «Настройки» (каналы)

ID	Задача	Критерий
`notif-10`	Маршрут `/settings`, пункт в сайдбаре (только admin JWT)	Страница открывается
`notif-11`	Блок Telegram: enabled, bot token, chat id, min severity (`info`/`warning`/`high`/`critical`)	GET/PUT API + форма
`notif-12`	Хранение: вариант A — запись в БД `notification_channels` + fallback на env; вариант B — только env, UI read-only	Решение в комментарии к PR
`notif-13`	Секреты: токен не возвращать целиком в GET (маска `***…last4`); запись только при изменении	Без утечки в логах/UI
`notif-14`	Кнопка «Проверить Telegram» → тестовое сообщение	200 / понятная ошибка

P2 — Email и webhook (после Telegram)

ID	Задача	Критерий
`notif-20`	SMTP: host, port, user, from, to, TLS — по аналогии с RDP `login_monitor.settings`	Отправка тестового письма
`notif-21`	Webhook: URL, optional secret header, JSON payload (event/problem)	POST на httpbin/staging
`notif-22`	TZ F-NOT-02 урезанно: правило «severity ≥ X → каналы» без сложного конструктора	Одна строка в настройках

P3 — Качество сообщений (можно сдвинуть)

ID	Задача
`notif-30`	Шаблон TG ближе к агенту (HTML, поля user/ip/logon_type из `details`)
`notif-31`	Cooldown/dedup на уровне SAC (F-NOT-03) — не дублировать problem при burst
`notif-32`	F-NOT-05: daily report из SAC при exclusive (отдельный эпик)

Связь с агентами

UseSAC=off      → только агент (Telegram на хосте)
UseSAC=dual     → агент + SAC ingest (+ опционально SAC TG, риск дублей)
UseSAC=exclusive→ только SAC ingest; TG/email = настройки SAC (UI/env)

Оценка на день

Блок	Часы (оценка)
P0 док + notif-03 + smoke	2–3
P1 UI Settings + API Telegram	4–6
P2 webhook/email	+1 день

Минимум на завтра: notif-01 … notif-03 + черновик notif-10 … notif-14 (хотя бы API без полировки UI).

См. также

TZ.md §4.6 F-NOT-01 … F-NOT-05
agent-integration.md — режимы UseSAC
backend/app/config.py — telegram_*
backend/app/services/telegram_notify.py

5.4 KiB Raw Blame History Unescape Escape