Notifications
In-app announcements an admin sends to users.
Notifications are entirely admin-written announcements — no event on the platform (a finished build, an error, a quota being hit) generates one on its own. An admin writes a title and content (or has AI draft one) and sends it to some or all users.
#How they are produced
Sent from the Broadcast tab on the Knowledge → Admin page. The admin sets a title, content and type (general / feature / announcement); the target is either all email-verified users (the default) or a specific set of chosen users. "Generate with AI" drafts a title/content pair from a chosen model over RAGify's connected Ollama-compatible endpoint; the draft can be edited before sending.
Sending creates a separate notification row per targeted user (a bulk insert) — a single notification is never shared across multiple users.
| Type | Bell icon |
|---|---|
| feature | 🚀 |
| announcement | 📣 |
| general (and anything else) | 📢 |
#Who sees them
Notifications are per-user: each row belongs to a single user_id, and a user only ever sees what was sent to them. The page lives at '/panel/knowledge/notifications', but the notification bell itself sits in the panel's global header and is visible on every page, showing the unread count.
The bell picks up new notifications instantly over an SSE stream (/notifications/stream); if that connection drops, the panel falls back to refetching the unread count every 60 seconds so the bell doesn't go permanently stale.
#How they are cleared
Notifications are never deleted, only marked read. Clicking a notification (in the bell dropdown or on the full page) marks it read; "Mark all as read" marks all of that user's unread notifications at once. Both actions update the is_read and read_at fields — the row itself is never removed.