Notifications - edmozley/freeitsm GitHub Wiki

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 and tasks that are yours. 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. For a domain or a project, whose line says what happened (Bradford move: amber to red), the line is the newest one too.

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 domain I own is expiring, its certificate is expiring, or it changed ✅
The health of a project I manage changes ✅
A project I manage goes beyond a time or risk tolerance ✅
A stage of a project I manage ends in 7 days, and the day before ✅
A stage of a project I manage closes ❌

"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.

The same tab has two more ways of being told, both off until you turn them on (2.10.0):

On your desktop

Show desktop notifications makes each new item in the bell appear as a notification on your computer as well — in Edge on Windows, an ordinary Windows notification, the kind Outlook and Teams raise. You see it while working in another window, and clicking it opens the ticket or task.

  • Your browser asks first. Turning the switch on brings up the browser's own Allow notifications? question. Say no and the switch goes back off, with a line underneath saying how to allow them later (the padlock beside the address). A setting that is on but can never show anything would be a promise the page cannot keep.
  • Test shows a sample, so you can check it before relying on it.
  • FreeITSM has to be open in a tab. Minimised, or behind other windows, is fine. With the browser closed nothing arrives — see What it does not cover below.
  • Several tabs do not mean several pop-ups. The tabs share a note of what has already been shown.
  • A burst is not a flood. At most three appear at once; past that, one line says how many more are waiting in the bell.
  • Only things that reach the bell. The switches above still decide what counts — turning status changed off turns it off here too.

By email, when a task is yours

Email me when a task is assigned to me sends an email whenever a task lands on you: created with you as the owner, or handed to you by somebody else — from the board, the API, a workflow or a repeating task.

  • Nothing for your own actions. Assigning yourself a task sends nothing, as with the bell.
  • In your language. The email is written in your interface language, not that of whoever assigned it.
  • It needs a mailbox that can send. It goes out through the same mailbox as password resets and training reminders, and every one — sent or failed — is listed in the send log as Task assigned.
  • Bulk changes send nothing, for the same reason they put nothing in the bell.
  • It is separate from the bell's own task assigned switch, so you can have the email without the bell entry, or the other way round.

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.

Domains tell their owner and projects tell their project manager.

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.

The portal has one too

Since portal managers, the self-service portal has the same bell for every manager - telling them, when System → Managers says to, that someone on their team has raised a ticket. It looks and works exactly like this one, because it is this one.

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.

Desktop notifications need https, and an open tab. Browsers only allow them on a site opened over https, so an install on plain http cannot offer them; the bell itself needs neither. And they come from the open page, so a closed browser gets nothing. Arriving with the browser closed would need Web Push — a push service, signing keys and a background worker — which is a separate piece of work, not a setting.

No email for anything but task assignment. The task email is the only one so far; everything else is the bell (and the desktop notification, if you have it on).

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