Skip to content

feat(alerts): realtime alert notifications over SMTP + in-app (#25) - #144

Draft
Jovonni wants to merge 2 commits into
masterfrom
feat/realtime-alert-notifications
Draft

feat(alerts): realtime alert notifications over SMTP + in-app (#25)#144
Jovonni wants to merge 2 commits into
masterfrom
feat/realtime-alert-notifications

Conversation

@Jovonni

@Jovonni Jovonni commented Aug 13, 2026

Copy link
Copy Markdown
Collaborator

What

Delivers realtime alerts (requested in #25) as email (SMTP) + in-app notifications, wired end-to-end through the pieces we already have — no new tables.

How it reuses existing infrastructure

  • Config: stored in the existing integration_settings table (integration_type="smtp"), loaded with an env-var fallback exactly like ChatService does for LLM providers. smtp is added to the settings whitelist, the password is masked on read, and there's a /test connectivity probe.
  • Delivery point: hooks RuleEngine._fire_alert — the single choke point where every rule-fired alert is created. When the alert node's action is a notify action, it dispatches email + in-app. Best-effort: a mail outage can never block alert creation.
  • In-app: creates rows in the existing notifications table (type alert), so they surface in the notification center already wired into the frontend + notifications router.
  • Rule canvas: the alert node gains a "fire alert + notify" action and an optional recipients field (persisted in flow_graph, read by the engine). No new node type.
  • Settings UI: a new Notifications section with an Email (SMTP) card, driven by the existing data-driven integrations panel.
  • SDK: openuba.send_alert(...) lets Python models raise alerts (and optionally notify). Backed by a new POST /api/v1/alerts that owns SDK alerts under a system SDK Alerts rule (alerts require a rule_id).

Tests (own subsuite, CI-wired)

core/tests/test_services/test_notification_service.py, test_rule_engine_notify.py, and core/tests/test_api_routers/test_settings_smtp.py28 unit tests, all mocked (no SMTP server or DB container): recipient normalization, config load (DB + env), STARTTLS/SSL send paths, error-swallowing, notify-action gating, rule-engine dispatch wiring, and settings whitelist/masking/_test_smtp.

Local: backend suite green, tsc --noEmit clean, next lint clean, next build green.

Closes #25

Adds an SMTP email channel and in-app notifications for detections, wired
through the existing rule engine, rule canvas, settings, and SDK — no new
tables (reuses integration_settings + notifications).

- notification_service: EmailService (config from integration_settings with
  SMTP_* env fallback, à la ChatService) + AlertNotifier (email + per-user
  in-app notification), best-effort so delivery never blocks alerting
- rule_engine._fire_alert dispatches notifications when the alert node action
  is a notify action, threading the node's optional recipients
- settings: register 'smtp' integration, mask the password, add a /test probe
- rule canvas: 'fire alert + notify' action + optional recipients field
- settings UI: Notifications section with an Email (SMTP) integration card
- POST /api/v1/alerts to raise alerts directly (owns them under a system
  'SDK Alerts' rule) with optional notify
- SDK: openuba.send_alert(...) for models
- dedicated test subsuite (28 unit tests, no container needed)

Closes #25
@Jovonni Jovonni mentioned this pull request Aug 13, 2026
The workspace image build failed generating pyspark metadata ('setuptools is
not available in the build environment'). Upgrade build tooling right after the
base image so isolated sdist builds resolve setuptools. Unblocks the workspace
CI triggered by the sdk/ change in this branch.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Realtime Alerts

1 participant