NexTool Solutions

The cheapest ticket is the one that never gets opened. When a user sees a clear notice on the GLPI screen itself before reporting something already known, they do not open the ticket - and the service desk queue stops filling with duplicates about the same maintenance or the same incident. The News plugin solves exactly this: alert, announcement and maintenance banners inside the interface, for technicians and for people using the self-service portal. Running client environments day to day, we learned that turning the banner on is the easy part; what separates useful communication from a cluttered portal is the right targeting, the end date, and the discipline to remove the notice once it no longer applies.

Static notice vs technician notification: do not confuse them

Before installing anything, it helps to separate two different problems. The static notice (News plugin, or the native Public Reminders) speaks to whoever has not opened the ticket yet - it is preventive communication on the self-service portal and the dashboard. The technician notification (native e-mail or the Smart Notify bell) speaks to whoever is already handling the ticket. The common mistake is assuming one covers the other: switching off e-mail because there is a banner, or posting a banner expecting the technician to be alerted about a followup. They are complementary layers. The News plugin is the outer layer - the one that stops the ticket from being born.

Installing and locating the News plugin

News is distributed through the GLPI Marketplace and the official repository. After downloading it into plugins/news, install and enable it. From the command line, run it as the web server user - the trap here is using --allow-superuser or running as root, which writes files with the wrong owner and later breaks cron:

# GLPI 10/11 (CLI) - run as the web server user, never with --allow-superuser:
docker exec --user apache glpi php bin/console glpi:plugin:install news
docker exec --user apache glpi php bin/console glpi:plugin:activate news

# UI alternative: Setup > Plugins, Install button and then Activate.

With the plugin enabled, alert management usually lives under Tools > Alerts (the label may vary by version). Each alert has four decisions that matter: the type, the message, where and to whom it appears, and for how long.

Anatomy of an alert: the fields that matter

The type defines the color and the semantic reading of the banner - the user decodes the urgency before reading the text. Use the semantics sparingly: if everything is red, nothing is urgent.

The visibility controls two axes: where the banner appears (the technician central screen, the self-service portal, the login screen) and to whom (everyone, specific profiles, groups or entities). This is where the trap that causes the most embarrassment in multi-entity installations lives: creating the alert on the root entity with "recursive" enabled makes the notice leak into the self-service of EVERY client sharing the same instance. A maintenance announcement for Client A shows up for Client B. In sustaining operations, the rule is to scope every alert to the specific entity and only use the recursive root for notices that apply to the whole base, such as a ticket-opening policy.

The period (start and end date) is the field everyone underestimates - and it is the one that clutters the portal most over time.

Ready-to-use template: scheduled maintenance banner

The message accepts HTML, so you can standardize a readable banner instead of a running paragraph. This template makes clear what goes down, when it comes back and what the user should do. Copy it, adjust the values and paste it into the message field:

<strong>Scheduled maintenance - E-mail system</strong><br>
Window: 15/07/2026, from 22h00 to 02h00 (local time).<br>
Impact: webmail and message sending will be unavailable.<br>
What to do: postpone critical sends until after 02h00.<br>
<em>There is no need to open a ticket about this outage.</em>

That last line - "there is no need to open a ticket" - does more for queue reduction than the whole banner. It is the explicit instruction the user is looking for before deciding to report.

The "eternal alert" trap and the housekeeping SQL

In every installation we take over to sustain, the pattern repeats: the self-service portal has piled up six or eight old banners that nobody expired. The user learns to ignore the whole strip - it is banner blindness - and when a notice that matters arrives, nobody reads it. The root cause is almost always an alert with no end date. Worse still is the "we are aware of the slowness" banner that stayed up three days after the incident was resolved, signaling an outage that is over and eroding trust in the channel. We adopted a monthly sweep straight in the database. First find the real schema (column names vary between plugin versions), then hunt for the eternal ones:

-- 1. Find the News plugin alerts table:
SHOW TABLES LIKE 'glpi_plugin_news_%';

-- 2. Check the real column names (they vary by plugin version):
DESCRIBE glpi_plugin_news_alerts;

-- 3. "Eternal" alerts - no end date, the root cause of banner blindness:
SELECT id, name, type, date_start, date_end
FROM glpi_plugin_news_alerts
WHERE date_end IS NULL OR date_end = '0000-00-00 00:00:00'
ORDER BY date_start;

-- 4. Alerts still active whose window has already passed (forgot to remove):
SELECT id, name, type, date_end
FROM glpi_plugin_news_alerts
WHERE date_end IS NOT NULL
  AND date_end < NOW()
ORDER BY date_end DESC;

Query 4 is the one that surprises the client most: it lists the incident that "was already resolved" but is still on the screen. Running this once a month keeps the channel credible - and it is cheap.

News, Public Reminders or Smart Notify: which to use

Not every announcement needs a plugin. GLPI has native Public Reminders, and NexTool maintains Smart Notify for the dynamic side. Each one solves a slice:

In practice: use the native Public Reminders for a simple note without installing anything; the News plugin when you need a colored banner by type, targeting by screen and a notice on the login page; and Smart Notify for the other side of the coin - telling the technician, in near real time, about followups, validations and tasks inside GLPI itself. They do not compete: News stops the ticket from being born, Smart Notify speeds up the ticket that already exists.

Communication best practices (from sustaining operations)

• Every message has an end date. No exceptions. If you do not know when the notice expires, you do not know why you are publishing it.
• Announce maintenance 24h in advance and keep the banner up until the end of the window. For planned windows announced ahead of time, we saw the duplicate queue about "system down" drop significantly - treat that as an honest range, not a magic number.
• Remove the incident banner as soon as it is resolved. An outage notice still up after the outage is worse than no notice at all.
• Do not stack banners. Three simultaneous notices on self-service is already noise; nobody reads the fourth.
• Scope by entity on multi-client instances. Recursive at the root only for what applies to everyone.
• Colors with meaning. Red means an active incident, not "read carefully".

At NexTool we treat communication in GLPI as part of the sustaining operation: we configure the right channels, define the notice expiration policy and combine static communication with dynamic notification for the client's estate. If you want to take this beyond the banner, the Smart Notify module covers the technician side, and our sustaining team helps design the full flow.

Reviewed by the NexTool Solutions team.