Notifications

Notifications

The bell in the header: what puts something in it, what deliberately does not, and how to change that for yourself. The technical version is Notifications — Developer Guide.

Asked for in discussion #55 by Daniel (dschipfel). Shipped in bbd49c50.

---

What it is

A bell at the top of every screen, in every module, showing what has happened on the tickets assigned to you. A red count is how many you have not read. Click one and it opens the ticket.

That is the whole of it. The interesting part is what it doesn't do.

---

🔑 It is built to stay switched on

A notification bell has one failure mode that matters: it fills up faster than anyone can read it, everybody starts ignoring it, and the feature is dead while still appearing to work. An analyst carrying forty tickets would get there within a day.

So four rules apply to everything, and they are not optional extras:

1. You are never told about your own actions

You changed the status. You do not need a notification saying the status changed.

This removes more noise than the other three put together, because analysts make most of the changes on their own tickets.

The exception is deliberate: something the system did — an SLA warning, for instance — still reaches you even though the ticket is yours, because nobody performed that action.

2. Bulk changes produce nothing

Select fifty tickets, change the status, and the person they belong to gets no notifications rather than fifty.

Everything else about a bulk change is unaffected: workflows fire, the audit trail records every ticket. Only the bell is quiet.

3. Several changes to one ticket become one entry

If somebody changes the status, then the priority, then adds a note — that is one line in your bell showing ×3, not three lines.

Entries merge while they are unread and within half an hour of each other. The line shows the most recent thing that happened, so if a ticket was assigned to you and then the requester replied, you see the reply.

4. Only things worth interrupting you for are on

Event	On by default
A ticket is assigned to me	✅
A requester replies to my ticket	✅
Someone adds a note to my ticket	✅
Someone changes the status of my ticket	✅
Someone changes the priority of my ticket	✅
My ticket is approaching its SLA target	✅
My ticket breaches its SLA target	✅
A ticket is raised	❌
A task is created for me	❌
A task of mine is completed	❌

"A ticket is raised" is off because that is what the inbox is for. A bell for every new ticket on a busy desk is the definition of noise.

---

Changing it for yourself

Preferences → Notifications. Every type above has a switch. It is your setting and changes nothing for anyone else — there is no administrator setting that overrides it.

If the bell is still busier than you want, the two worth turning off first are status changed and priority changed: they are the highest-volume and the least likely to need you immediately.

---

Who gets told

The analyst the ticket is assigned to, and only them.

That is a deliberate limit. The alternative — telling everyone who ever touched a ticket — cannot be switched off and turns the bell into exactly the firehose the four rules exist to prevent.

The honest cost: a ticket you worked on all week goes quiet the moment it is reassigned. If that becomes a real problem, a Watch button is the answer and nothing built so far would need to change.

---

What it does not cover

War Room mentions are separate. Being @mentioned in a channel lights up the speech-bubble icon next to the bell, not the bell itself. Both work; they are simply two widgets. See War Room.

No desktop pop-ups. The browser Notification API only works over HTTPS, and many installations run on plain HTTP where it is unavailable regardless of what we build. The in-app bell needs no HTTPS at all.

SLA notifications need the SLA cron. cron/sla_breach_check.php is what produces SLA warnings and breaches. If that is not scheduled, those two types will never fire — the wiring is there, the trigger is not. See Installation.

---

Related pages

• Notifications — Developer Guide
• Workflows — the same events drive the bell and your automation rules
• War Room — mentions, which are the other notification surface