-
-
Notifications
You must be signed in to change notification settings - Fork 0
Notifications
Since IRIS-NG-v2.0.0, IRIS-NG has a real notification system: an event catalog, a
global bell, per-user preferences over org defaults, optional email delivery, and
@mentions everywhere comments exist. It answers "what was addressed to me" — the
existing per-case bell (Case Notifications) keeps answering "what
changed in this case", and the two coexist in the header.
Twelve events, each individually configurable:
| Event | Fires when |
|---|---|
| Mention | Someone @mentions you in any comment surface or war-room chat |
| Task assigned | You are newly added to a case task's assignees, or a war-room task |
| Case assigned | A case becomes yours |
| Case updated | A case you own is updated by someone else |
| Alert assigned | An alert becomes yours |
| Alert escalated | An alert you own is escalated |
| Cluster assigned | An alert cluster becomes yours |
| Review requested | You are named reviewer on a case |
| War-room membership | You are added to a war room |
| War-room message | A message is posted in a room you belong to — off by default (it fires per message; opt in per room-heavy workflows) |
| SitRep published | A situation report is published in your room |
| Module notification | An installed module emits a notification addressed to you |
A few deliberate semantics:
- Assignment events fire on the transition, not on every save of an already-assigned object.
- Your own actions do not notify you — with three exceptions where the action is an explicit address rather than incidental self-activity: @mentioning yourself, requesting a review from yourself, and assigning a task to yourself. On a small or single-operator instance, dropping those would make the events permanently silent.
- Plain alert ingest emits nothing. Notification is about ownership and address, not traffic.
Each event can be delivered in-app (the bell) and/or by email. Resolution is per event: your own setting wins; anything you have not overridden inherits the org default; and where the org has set nothing, the code default is in-app on, email off.
- Your matrix lives on your profile page under Notifications.
- Org defaults live at Settings → Notifications (administrators).
- Email delivery is off by default and requires the SMTP settings from Mail Rules' Server settings → Mail tab. Turning email off also stops queued-but-unsent messages — the switch is checked at send time, not at queue time.
The global bell shows unread notifications with per-item read state and Mark all read. It appears in both headers (dashboard/manage pages and case pages).
Following is the pull side of the same coin: a star on cases and alerts.
- The Home page (
/home, the default landing after login) lists your open alerts, pending tasks, recent case activity — and the objects you follow, so a starred case is one click away regardless of activity. - The case header shows a follower count. Counts never leak existence: an object you cannot see reports nothing, not even a number.
- Notification writes never break the action that triggered them — a comment posts even if notification delivery hiccups, and the failure is logged rather than surfaced as a comment error.
- Everything is additive under
/api/v2/(API Reference); no schema or permission changes affect existing clients.