Notifications¶
The bell in the header collects what currently needs your attention: open tasks, new tickets, calibrations coming due, incoming order requests and messages from colleagues.
The number on the bell counts unread notifications only (orders and messages). From eleven onwards it shows "10+". The remaining figures are running counts and live inside the popover.
What the bell shows¶
Running counts¶
| Entry | Meaning | Requires |
|---|---|---|
| My tasks | Tasks due today or earlier (or with no due date) that involve you: created by you, assigned to you, assigned to your group, or listed as an additional recipient. Finished tasks are not counted. | notepad_view |
| My tickets | New tickets where you are the reporter, assignee, group member or in CC. | support_view |
| Calibrations due | Devices whose next calibration is coming up; overdue ones are highlighted in red. | inventory_view |
A row you lack the permission for is not rendered at all.
The task count deliberately reflects your work. Even with the "All tasks (global)" permission you only see your own here — the full overview is the task list.
Notifications¶
Two categories with separate read state:
- Messages — what someone sent you personally or to your group.
- Orders — newly received offer requests and new orders. Visible to anyone
holding
bookings_view, typically sales and back office.
Sending a message¶
With the Send notifications permission (notification_send), a Send
message button appears at the top of the popover and on the notifications
page.
- Pick the recipients (several are possible).
- Enter a subject and optionally a message.
- Optionally enable "Create task as well" and set a due date.
Without the checkbox it is a plain message. With it, each recipient also gets a real task in the task module — with assignee, due date and status, visible in the list and calendar. That is the point of the split: messages are the delivery channel, the task module remains the authoritative place work is tracked.
Holders of Send notifications to groups (notification_broadcast) can
address a whole user group instead of individual people.
Turning a message into a task later¶
Every incoming message carries a Create task from message action. It creates a task assigned to you; the notification then links to that task and counts as read. A message can only be taken on once.
Read state¶
- Clicking a notification marks it read.
- Mark all as read clears the currently open category. Orders and messages are handled separately: clearing orders does not clear your messages.
All notifications¶
Show all notifications opens the archive at /notifications with filters by
category and "unread only", plus paging. The menu entry also sits under
Support → Notifications. No dedicated permission is needed — every user has
an inbox.
Refresh¶
Counters refresh roughly once a minute, plus on sign-in, when you return to the browser tab, and after leaving the task, ticket or order pages. A notification may therefore take up to a minute to appear in the bell.
By email as well¶
The bell only reaches whoever signs in. To get notifications in your inbox too, set it under My profile → Notifications by email:
| Setting | Effect |
|---|---|
| As the installation | Whatever the operator has set applies. |
| No emails | Bell only. |
| Immediately, per event | One mail per notification. |
| Once a day, batched | One mail in the evening with everything that came in and is still unread. |
The digest lists unread items only. Anyone who looks at the bell during the day gets correspondingly less in the evening — and no mail at all with nothing open.
Shipped switched off
The installation default is "No emails". That is deliberate: an update that pushes the whole notification traffic into inboxes that never asked for it would be the wrong kind of surprise. The operator changes the default, or each user decides for themselves.
Different per area¶
Below the general setting each area can be set separately — the typical case is orders immediately, messages batched. Without an explicit choice an area follows the setting above.
The digest then lists only the batched areas. Whatever already went out individually during the day does not appear again in the evening.
How the mails look¶
Mails go out as HTML through the templates Benachrichtigung and Benachrichtigungen (Zusammenfassung) under Administration → Email. Change the wording or the layout there — it is one template for every notification kind, not one per kind.
With the template missing (on an installation where mailer:seed-templates never
ran) a fixed text goes out instead. The mail is not lost.
Every mail links to /notifications, not to the individual record — the entry
takes you on from there just as it does in the bell. And: whoever sent a
notification themselves gets no mail about it.
The daily run hangs off the scheduler (task Notification digest, see Operations). With the scheduler stopped the digest stays away; immediate delivery goes through the queue and is unaffected.
Retention¶
Notifications are removed automatically after 90 days (configurable via the
notifications/retention_days setting). The running counts are unaffected —
they are recomputed on every request.