Repository navigation
Live Updates Developer Guide
How a FreeITSM page keeps up with changes other people make. Built for #267 (5.0.0). User guide: Live updates.
- Page 1 (this page): why it is built this way, the files, one beat end to end, the endpoint, every signature with its PHP and SQL, the indexes, cost, server-side traps, the PHP test.
-
Page 2:
live-pulse.js, the fetch wrapper and "mine", each screen's wiring and busy rules in JavaScript, the browser checks, and adding live updates to another screen.
The one-line version: every analyst page loads assets/js/live-pulse.js. Parts of the page watch() the topics they show. Every 15 seconds, while the tab is visible, the page sends one GET api/system/pulse.php?topics=β¦. The server answers with an md5 per topic, built from a few "newest change" values (each one an indexed query). When a hash moves, that part's callback runs, and the callback decides whether it may redraw now or must show the "Updated Β· Refresh" prompt.
Before 5.0.0 each part of the app kept itself current in its own way, or not at all:
| Part | Before | Problem |
|---|---|---|
| Ticket list | 60 s loop in tickets/index.php; refreshed when get_inbox_activity.php's newest message id moved |
a colleague changing status, priority, owner or team never moved it |
| Open email ticket | nothing | stale until you clicked away and back |
| Open chat ticket | its own 15 s setInterval in inbox.js
|
a second loop, thread only |
| Tasks board, open task | nothing | stale until reload |
| Bell | its own 60 s loop | up to a minute late |
One more loop per screen would have made it worse. So instead there is one mechanism that sends one request per page per beat, stops entirely in a background tab, and leaves the "never wipe work in progress" decision with the part that owns the screen, using one shared prompt.
Why polling, not websockets. FreeITSM installs are plain PHP + MySQL behind Apache or nginx, often on shared or locked-down hosting. A socket server is a second long-running process to install, secure, keep alive and proxy. Short polling needs nothing new. At 15 seconds and one cheap request per visible tab, the load is negligible (section 7).
Why hashes of "newest change" values, not a change log. A log table written from WorkflowEngine::dispatch() would say exactly what changed. It was rejected because:
-
Not every write dispatches an event. 24 files update
ticketsand 13 updatetasks, and some paths announce nothing (#266 was exactly that). -
The values already exist. Almost every write stamps
updated_datetimeor adds a message, note or history row. Reading the newest of those catches writes from any path, including ones written before this feature existed. - Nothing to grow, prune or index, and nothing extra on the write path.
The cost of this choice is the first trap in section 8.
| File | π¨ | Role |
|---|---|---|
includes/live_pulse.php |
βοΈ |
livePulseSignatures(), one function per topic, livePulseOne(), livePulseSeconds(), LIVE_PULSE_MAX_TOPICS
|
api/system/pulse.php |
π | the endpoint (section 4) |
includes/waffle-menu.php renderNotificationBell()
|
π₯οΈ | prints window.FREEITSM_LIVE and loads live-pulse.js before the bell, on every analyst page |
assets/js/live-pulse.js |
π₯οΈ |
window.LivePulse - page 2
|
tickets/index.php, assets/js/inbox.js, assets/js/ticket-workspace.js
|
π₯οΈ | the ticket list and the open ticket - page 2 |
assets/js/tasks.js |
π₯οΈ | the board and the open task - page 2 |
assets/js/notification-bell.js |
π₯οΈ | the bell - page 2 |
system/preferences/index.php, includes/preference_templates.php
|
π₯οΈ | the live_updates preference |
database/freeitsm.sql, includes/db_verify_indexes.php (generated) |
ποΈ | two new indexes (section 6) |
tests/live-pulse.php |
π§ͺ | section 9 |
tickets page (visible tab) server
βββββββββββββββββββββββββ ββββββ
ticket list watch('tickets') ββ
open ticket watch('ticket:1451') ββ every 15 s βββΊ GET api/system/pulse.php
bell watch('notifications') ββ ?topics=tickets,ticket:1451,notifications
β
livePulseSignatures() β per topic: module gate,
β company scope, a few
βΌ indexed newest-row reads
βββββββββββββββββββββ { sig: { tickets: "9fβ¦", "ticket:1451": "c2β¦", notifications: "41β¦" } }
for each topic:
first answer β baseline, nothing runs
same hash β nothing
hash moved β callback(topic, { mine })
null β stored, nothing runs (gone / not allowed)
The page side - when beats happen, the debounce, "mine", other tabs - is page 2 Β§1.
renderNotificationBell() runs on every analyst page (the portal has its own bell and no live updates). It reads the analyst's preference and prints it before loading the script, so the bell that follows can watch:
// includes/waffle-menu.php - renderNotificationBell()
$url = defined('BASE_URL') ? BASE_URL : $path_prefix;
require_once __DIR__ . '/live_pulse.php';
$liveSeconds = 15;
try { $liveSeconds = livePulseSeconds(connectToDatabase(), (int)$_SESSION['analyst_id']); } catch (Throwable $e) { /* the default */ }
echo '<script>window.FREEITSM_LIVE = ' . json_encode(['seconds' => $liveSeconds, 'url' => $url], JSON_HEX_TAG | JSON_UNESCAPED_SLASHES) . ';</script>'
. '<script src="' . htmlspecialchars($url) . 'assets/js/live-pulse.js?v=3"></script>';
notificationBellRender($url, [ /* β¦ */ ]);// includes/live_pulse.php - 15 (default), 30, 60 or 0 = off. Anything else reads as the default.
function livePulseSeconds(PDO $conn, int $analystId): int
{
try {
$st = $conn->prepare("SELECT preference_value FROM user_preferences WHERE analyst_id = ? AND preference_key = 'live_updates'");
$st->execute([$analystId]);
$v = $st->fetchColumn();
} catch (Throwable) {
$v = false;
}
return in_array((string)$v, ['15', '30', '60', '0'], true) ? (int)$v : 15;
}BASE_URL, not $path_prefix: on a pretty URL served deeper than its file, the filesystem prefix points one folder too high (the same lesson the bell learned).
GET api/system/pulse.php?topics=tickets,ticket:42,tasks,task:7,notifications
β 200 { "success": true, "sig": { "tickets": "9f3aβ¦", "ticket:42": "c2d1β¦", "tasks": "β¦", "task:7": null, "notifications": "β¦" } }
β 401 { "success": false, "error": "Not authenticated" }
// api/system/pulse.php
session_start(['read_and_close' => true]); // a beat never holds the session lock against the page's real requests
require_once '../../config.php';
require_once '../../includes/functions.php';
require_once '../../includes/tenancy.php';
require_once '../../includes/live_pulse.php';
header('Content-Type: application/json');
header('Cache-Control: no-store'); // no proxy may answer with an old hash
if (!isset($_SESSION['analyst_id'])) {
http_response_code(401);
echo json_encode(['success' => false, 'error' => 'Not authenticated']);
exit;
}
try {
$topics = array_filter(array_map('trim', explode(',', (string)($_GET['topics'] ?? ''))));
$conn = connectToDatabase();
echo json_encode(['success' => true, 'sig' => (object)livePulseSignatures($conn, (int)$_SESSION['analyst_id'], $topics)]);
} catch (Throwable $e) {
error_log('[api/system/pulse] ' . $e->getMessage());
echo json_encode(['success' => false, 'error' => 'Could not check for changes.']);
}It is a GET and writes nothing, so tests/get-must-not-write.php passes it as it is. (object) keeps an empty answer as {} rather than [].
// includes/live_pulse.php
const LIVE_PULSE_MAX_TOPICS = 12;
function livePulseSignatures(PDO $conn, int $analystId, array $topics): array
{
$out = [];
foreach (array_slice(array_values(array_unique($topics)), 0, LIVE_PULSE_MAX_TOPICS) as $topic) {
$topic = (string)$topic;
try {
if ($topic === 'tickets') $out[$topic] = livePulseTickets($conn, $analystId);
elseif ($topic === 'tasks') $out[$topic] = livePulseTasks($conn, $analystId);
elseif ($topic === 'notifications') $out[$topic] = livePulseNotifications($conn, $analystId);
elseif (preg_match('/^ticket:(\d+)$/', $topic, $m)) $out[$topic] = livePulseTicket($conn, $analystId, (int)$m[1]);
elseif (preg_match('/^task:(\d+)$/', $topic, $m)) $out[$topic] = livePulseTask($conn, $analystId, (int)$m[1]);
} catch (Throwable $e) {
error_log('[live_pulse] ' . $topic . ': ' . $e->getMessage());
$out[$topic] = null; // a part-upgraded install: that part simply does not refresh
}
}
return $out;
}
/** One value: the first column of the first row, or ''. */
function livePulseOne(PDO $conn, string $sql, array $params): string
{
$st = $conn->prepare($sql);
$st->execute($params);
$v = $st->fetchColumn();
return $v === false || $v === null ? '' : (string)$v;
}- Unknown topics are left out, not answered, so a typo in a page's topic is visible as "never fires".
- At most 12 topics a request. A page shows a handful, so this only matters against a crafted request.
- An exception answers null for that topic only, so one missing table doesn't take every part of the page down with it.
Every value is one query that walks an index from the newest row and stops at the first row the analyst may see (ORDER BY β¦ DESC LIMIT 1), or a MAX() / COUNT() on an indexed column. The values are joined with | and md5'd with the topic name. Only the hash leaves the server.
function livePulseTickets(PDO $conn, int $analystId): ?string
{
if (!analystCanAccessModule($conn, $analystId, 'tickets')) return null;
[$f, $p] = ticketTenantFilter($conn, $analystId, 't');
$parts = [
livePulseOne($conn, "SELECT t.updated_datetime FROM tickets t WHERE 1 = 1{$f} ORDER BY t.updated_datetime DESC LIMIT 1", $p),
livePulseOne($conn, "SELECT t.id FROM tickets t WHERE 1 = 1{$f} ORDER BY t.id DESC LIMIT 1", $p),
livePulseOne($conn, "SELECT e.id FROM emails e JOIN tickets t ON t.id = e.ticket_id WHERE 1 = 1{$f} ORDER BY e.id DESC LIMIT 1", $p),
livePulseOne($conn, "SELECT n.id FROM ticket_notes n JOIN tickets t ON t.id = n.ticket_id WHERE 1 = 1{$f} ORDER BY n.id DESC LIMIT 1", $p),
livePulseOne($conn, "SELECT a.id FROM ticket_audit a JOIN tickets t ON t.id = a.ticket_id WHERE 1 = 1{$f} ORDER BY a.id DESC LIMIT 1", $p),
livePulseOne($conn, "SELECT COUNT(*) FROM tickets t WHERE t.deleted_datetime IS NOT NULL{$f}", $p),
];
return md5('tickets|' . implode('|', $parts));
}| Value | Catches |
|---|---|
newest updated_datetime
|
status, priority, owner, team, subject - every write that stamps the row, including workflow actions that write it directly (set_ticket_status) |
| newest ticket id | a new ticket |
newest emails.id
|
a reply, a chat message, a collected email |
newest ticket_notes.id
|
a note |
newest ticket_audit.id
|
a change that is recorded but doesn't stamp the row; also breaks ties between two writes in the same second |
| trash count | binning or restoring through the REST API, which writes no history row and doesn't stamp the row (section 8) |
ticketTenantFilter() is the inbox's own company scope, including the "All companies" view, so the hash moves for exactly the tickets the list would show. Deleted rows are not filtered out of the updated_datetime read, so binning a ticket also moves it. On a single-company install $f is '' and WHERE 1 = 1 keeps the SQL valid.
function livePulseTicket(PDO $conn, int $analystId, int $ticketId): ?string
{
if ($ticketId <= 0 || !analystCanAccessModule($conn, $analystId, 'tickets')) return null;
$row = $conn->prepare("SELECT updated_datetime, deleted_datetime FROM tickets WHERE id = ?");
$row->execute([$ticketId]);
$t = $row->fetch(PDO::FETCH_ASSOC);
// analystCanAccessTicket() is a company check, true for any id on a single-company
// install - so the row is read first (found in #277).
if (!$t || !analystCanAccessTicket($conn, $analystId, $ticketId)) return null;
$parts = [
(string)$t['updated_datetime'], (string)$t['deleted_datetime'],
livePulseOne($conn, "SELECT MAX(id) FROM emails WHERE ticket_id = ?", [$ticketId]),
livePulseOne($conn, "SELECT MAX(id) FROM ticket_notes WHERE ticket_id = ?", [$ticketId]),
livePulseOne($conn, "SELECT MAX(id) FROM ticket_audit WHERE ticket_id = ?", [$ticketId]),
];
return md5("ticket:$ticketId|" . implode('|', $parts));
}A ticket that doesn't exist and a ticket the analyst can't open both answer null. The two cases are deliberately indistinguishable, so the endpoint can't be used to probe for ids.
function livePulseTasks(PDO $conn, int $analystId): ?string
{
if (!analystCanAccessModule($conn, $analystId, 'tasks')) return null;
[$f, $p] = activeTenantReadFilter($conn, $analystId, 't'); // the board's own scope (api/tasks/list.php)
$parts = [
livePulseOne($conn, "SELECT t.updated_datetime FROM tasks t WHERE 1 = 1{$f} ORDER BY t.updated_datetime DESC LIMIT 1", $p),
livePulseOne($conn, "SELECT COUNT(*) FROM tasks t WHERE 1 = 1{$f}", $p), // a delete moves nothing else
livePulseOne($conn, "SELECT e.id FROM task_events e JOIN tasks t ON t.id = e.task_id WHERE 1 = 1{$f} ORDER BY e.id DESC LIMIT 1", $p),
];
return md5('tasks|' . implode('|', $parts));
}
function livePulseTask(PDO $conn, int $analystId, int $taskId): ?string
{
if ($taskId <= 0 || !analystCanAccessModule($conn, $analystId, 'tasks')) return null;
$row = $conn->prepare("SELECT updated_datetime FROM tasks WHERE id = ?");
$row->execute([$taskId]);
$updated = $row->fetchColumn();
if ($updated === false || !analystCanAccessTask($conn, $analystId, $taskId)) return null;
$parts = [
(string)$updated,
livePulseOne($conn, "SELECT MAX(id) FROM task_comments WHERE task_id = ?", [$taskId]),
livePulseOne($conn, "SELECT MAX(id) FROM task_events WHERE task_id = ?", [$taskId]),
livePulseOne($conn, "SELECT MAX(id) FROM task_audit WHERE task_id = ?", [$taskId]),
livePulseOne($conn, "SELECT COUNT(*) FROM tasks WHERE parent_task_id = ?", [$taskId]), // a subtask added or removed
];
return md5("task:$taskId|" . implode('|', $parts));
}-
The task count is there because deleting a task leaves the newest
updated_datetimewhere it was. -
The board's drag (
api/tasks/reorder.php) stampsupdated_datetime, and since #266 it also writestask_events.
function livePulseNotifications(PDO $conn, int $analystId): ?string
{
$parts = [
livePulseOne($conn, "SELECT COUNT(*) FROM notifications WHERE analyst_id = ? AND read_datetime IS NULL", [$analystId]),
livePulseOne($conn, "SELECT MAX(updated_datetime) FROM notifications WHERE analyst_id = ? AND read_datetime IS NULL", [$analystId]),
];
return md5("notifications|$analystId|" . implode('|', $parts));
}Both reads use ix_notif_unread (analyst_id, read_datetime, updated_datetime). updated_datetime is there because the router coalesces a burst of events on one record into one unread row and bumps its time, rather than adding a row (the unread count wouldn't move).
Two "newest updated_datetime" walks had no index to walk, so they would have been scans:
-- database/freeitsm.sql, in CREATE TABLE `tickets`
-- GH #267: live updates read the newest change.
KEY `ix_tickets_updated_datetime` (`updated_datetime`),
-- in CREATE TABLE `tasks`
-- GH #267: live updates read the newest change.
KEY `ix_tasks_updated_datetime` (`updated_datetime`),php scripts/gen_db_verify_indexes.php # writes includes/db_verify_indexes.php (650 indexes)
php scripts/gen_db_verify_indexes.php --check # CI: the generated list matches freeitsm.sql
Database Verify creates them on existing installs. The other reads use indexes that already existed: the primary keys of emails, ticket_notes, ticket_audit and task_events, their ticket_id / task_id keys, ix_tickets_deleted_datetime, and ix_notif_unread.
β οΈ The comment must be on its own line.dbVerifyParseIndexesFromSql()matches aKEYline with/^β¦KEYname(cols),?\s*$/, soKEY β¦ , -- commentis silently skipped. The generator reported the same 648 indexes until the comments were moved above.
-
One request per visible page per beat. At the default 15 seconds that is 4 a minute per tab somebody is looking at. Background tabs send nothing.
-
A tickets-page beat is about 12 small queries:
- list: 6 values;
- open ticket: 1 row plus 3
MAX()reads; - bell: 2 reads.
Each newest-row read stops at the first visible row.
-
Company scope adds
tenant_idconditions to the walk. On a multi-company install the walk may pass a few other companies' rows before it finds a visible one. That is bounded and cheap, and the same approach the old inbox marker used. -
The session is opened
read_and_close, so a beat never queues behind, or holds up, a real request from the same page. -
A slower beat: each analyst can choose 30 or 60 seconds. There is no install-wide override yet.
TRAP: a writer that touches nothing is invisible. A change that neither stamps
updated_datetimenor writes a message, note or history row won't refresh anybody's screen. New write paths should stampupdated_datetime. If they can't, add a value to the topic's signature, as was done for the trash.
TRAP: binning through the REST API.
TicketsService::deleteTicket($conn, $ctx, $id, false)andrestoreTicket(β¦, false)(the API passeswriteAudit = false) only do this:$conn->prepare("UPDATE tickets SET deleted_datetime = UTC_TIMESTAMP(), deleted_by = ? WHERE id = ?")No history row, no
updated_datetime. That was invisible until the trash count joined theticketssignature. Found while writing this guide;tests/live-pulse.phpnow covers it.
TRAP: only ever a hash. Every page calls this every 15 seconds. A raw id, time or count would make it a feed of other people's activity. The test checks the response contains no dates, ids or counts.
TRAP: read the row before the access check.
analystCanAccessTicket()andanalystCanAccessTask()are company checks. On a single-company install they are true for any id, including ones that don't exist.
TRAP: closure capture in tests. An arrow function captures by value when it is created.
fn($t) => livePulseSignatures($conn, $me, $t)defined before$meis set always asks as analyst 0, and every module gate says no. Usefunction ($t) use ($conn, &$me) { β¦ }.
Page-side traps (the background-writes one above all) are on page 2.
tests/live-pulse.php runs on a disposable install with Database Verify first. 22 checks:
// the shape of every check: look, change something as "somebody else", look again
$sig = function (array $topics) use ($conn, &$me) { return livePulseSignatures($conn, $me, $topics); };
$before = $sig(['tickets'])['tickets'];
$conn->prepare("UPDATE tickets SET deleted_datetime = UTC_TIMESTAMP() WHERE id = ?")->execute([$ticketId]); // the API's bin
$binned = $sig(['tickets'])['tickets'];
$conn->prepare("UPDATE tickets SET deleted_datetime = NULL WHERE id = ?")->execute([$ticketId]);
check('binning through the API (no history, no updated time) moves the list', $binned !== $before);
check('...and restoring it moves it back', $sig(['tickets'])['tickets'] === $before);- Nothing changed: two looks agree, and every topic answers a 32-character hash.
- Tickets: an updated time moves the list and that ticket but not the board; a note moves both; a history row moves the ticket; an API bin and restore moves the list and back.
-
Tasks: a new task moves the board; a comment moves the open task; deleting it moves the board, and the task then answers
null. - Bell: a new notification moves it.
-
Limits: a nonexistent ticket or task is
null; unknown topics are left out; at most 12 topics per request; the preference reads 15 by default and 0 when off. - The endpoint (forged session, real HTTP): a hash per topic, nothing but hashes, and 401 when signed out.
FREEITSM_TEST_DATABASE=<throwaway db> FREEITSM_TEST_URL=http://localhost/<that install> php tests/live-pulse.php
Next: page 2 - the browser side.
FreeITSM β an open-source IT Service Management platform Β· github.com/edmozley/freeitsm Β· MIT licence
- Installation
- β° Scheduled tasks (cron jobs)
-
Architecture
- β³ π§Ή Root folder tidy (URL routing)
- β³ π Database Integrity (FKs & constraints)
- β³ π οΈ Database Verification β Developer Guide
- β³ π§© Service Layer (UI + API share code)
- β³ πͺ€ Code traps (the TRAP: comments)
- β³ π Commenting for the Engineering wiki
- β³ π οΈ Engineering wiki scanner - Developer Guide
- β³ π Service-Layer progress
- π€ Contributing (read before a pull request)
- π§ͺ Developer tests
- π PDF exports moved to PDFKit (#254)
- AI Providers
- Internationalisation (i18n)
- Timezones & Time Handling
- π Date & Time Formats
- π± Currencies
- π§ The sidebar (optional module rail)
- π§© Preference templates
- π Display order (modules, Watchtower cards) β Developer Guide
- Theming & Dark Mode
- ποΈ Recent β getting back to what you were doing
- β¨οΈ Command palette (βK)
- π Searching inside tickets
- π Attached documents
-
MobileβFriendly
- β³ π« Mobile: Tickets
- β³ π» Mobile: Assets
- β³ π Mobile: Calendar
- β³ π Mobile: Knowledge
- β³ π¦ Mobile: Service Status
- β³ πΌ Mobile: Watchtower
- β³ π§© Mobile: Problem Management
- β³ π Mobile: Change Management
- β³ πΏ Mobile: Software
- β³ β Mobile: Tasks
- β³ π Mobile: Forms
- β³ π Mobile: Contracts
- β³ π Mobile: Domains
- β³ π Mobile: People
- β³ π Mobile: Projects
- β³ ποΈ Mobile: Files
- β³ π Mobile: LMS
- β³ πΊοΈ Mobile: CMDB
- β³ πΊοΈ Mobile: Network Mapper
- β³ π§ Mobile: Process Mapper
- β³ βοΈ Mobile: Workflow
- β³ π₯οΈ Mobile: System
- β³ π Mobile: Reporting
- β³ π Mobile: System Wiki
- β³ π Mobile: Self-Service Portal
- β³ π§° Mobile: Techniques & Tricks
-
Security
- Layer 1 β which modules you can enter
- β³ π§© Module Access Control
- β³ π οΈ Module Access β Developer Guide
- β³ π Switching modules off
- β³ π οΈ Module availability β Developer Guide
- β³ π Module availability β design (#217)
- Layer 2 β what you can administer
- β³ π Roles & Permissions
- β³ π οΈ Roles β Developer Guide
- β³ π€ Why capabilities are constants
- Layer 3 β the System module
- β³ π Admin Access Control
- Hardening
- β³ π Security review response 2026-08
- β³ π‘οΈ Security hardening 2026-08
- β³ π οΈ Security hardening 2026-08 β Developer Guide
- β³ π‘οΈ Round three β plain English
- β³ π οΈ Round three β Developer Guide
- β³ π‘οΈ CSRF protection (S4) β Developer Guide
- Single Sign-On (SSO)
- ποΈ LDAP & Active Directory
-
π¦ Microsoft Entra ID
- β³ π₯ Importing people and groups
- β³ π» Intune: assets to their primary user
- β³ π’ Organisation chart
- β³ π οΈ Entra directory sync β Developer Guide
- β³ π οΈ Entra import - review (#235)
- β³ π οΈ Entra follow-ups - review (#237-#240)
- β³ π οΈ Intune primary user - review (#236)
- β³ π οΈ Organisation chart - reviews (#242, #265)
- π CardDAV contact sync
- Browser Extension
- API Reference
-
π REST API β how it works
- β³ π Proposal: custom fields, inventory import and change evidence (#194)
- β³ π οΈ Custom fields, evidence + inventory - review (#195-#197)
- β³ π οΈ Long forms in a task's Work view - review (#198)
- β³ π οΈ Empty Procedures fold - review (#247)
- β³ π« REST API: Tickets
- β³ π» REST API: Assets
- β³ π΄ REST API: Problems
- β³ π REST API: Changes
- β³ π REST API: Knowledge
- β³ β REST API: Tasks
- β³ ποΈ REST API: CMDB
- β³ π REST API: Contracts
- β³ ποΈ REST API: Calendar
- β³ πΏ REST API: Software
- β³ π REST API: Domains
- β³ π¦ REST API: Service Status
- β³ βοΈ REST API: Morning Checks
- β³ π REST API: Forms
- β³ βοΈ REST API: Workflow
- β³ π·οΈ REST API: Cost centres
- β³ π REST API: Chart of accounts
- β³ π REST API: Projects
- β³ π‘οΈ API threat protection
- β³ π§βπΌ REST API: Analysts
- β³ πΊοΈ REST API: Network Mapper
- β³ π§ Using the API docs page
- β³ π OpenAPI specification
- β³ β OpenAPI: kept correct
- β³ π οΈ Maintaining the catalogue
- Watchtower
-
Tickets
- β³ Reply subject and replying to one message
- β³ π Live updates
- β³ π οΈ Watching a ticket - Developer Guide (1 of 2)
- β³ π οΈ CSAT delay and reminder - Developer Guide
- β³ π οΈ Ticket checklist step types - Developer Guide (1 of 2)
- β³ π οΈ Right-click Attach checklist - Developer Guide
- β³ π οΈ Checklists in the REST API - Developer Guide
- β³ π οΈ Inbox.js map β Developer Guide
- β³ π οΈ Floating windows & the file viewer β Developer Guide
- β³ π οΈ Tickets settings β Developer Guide
- β³ π Simpler ticket and task forms - design (#218)
- β³ ποΈ The ticket workspace
- β³ π Forms on tickets
- β³ π The ticket table
- β³ π Rota copy and paste β Developer Deep Dive
- β³ β Checklists & SOPs
- β³ βοΈ Mandatory fields
- β³ π§Ύ Custom ticket fields
- β³ π·οΈ Ticket categories
- β³ π§Ύ A type for every new ticket
- β³ π₯ Assigning tickets to a team, and escalation
- β³ π’ One board across every company
- β³ π Ticket dashboard β Developer Guide
- β³ Mailbox Authentication
- β³ π€ Email send log
- β³ π Attachment size limits and large emails
-
β³ Basic IMAP mailboxes
- β³ π Basic IMAP without the PHP extension (#257)
- β³ π οΈ Basic IMAP client β Developer Guide
- β³ π§ͺ Basic IMAP client β Testing and verifying
- β³ π οΈ Basic IMAP - Sent copy - Developer Guide (#270)
- β³ π οΈ Verifying a mail folder β Developer Guide
- β³ π οΈ Mailbox providers β Developer Guide
- β³ π οΈ How Gmail mail collection works β Developer Guide
- β³ Email rendering & images
- β³ SLA Management
- β³ WhatsApp channel
-
β³
βοΈ Telegram channel - β³ β CSAT company scope and filters β Developer Guide
- β³ π₯ Microsoft Teams channel
- β³ π¨οΈ Mattermost channel
- β³ π¬ Web chat channel
- β³ π£ Slack channel
- β³ π Linking tickets
- β³ β Record previews
- β³ π Ticket notes: internal or shared
- β³ ποΈ Canned responses
- β³ βοΈ Limiting replies to particular senders
- β³ π¨ Telling the analyst a ticket is theirs
- β³ βοΈ Email signatures
- β³ π The public web address
- β³ π’ Ticket numbering
- β³ π Raising a ticket for someone else
- β³ π Merging tickets
- β³ π Confidential tickets
- β³ π₯ Portal managers
- β³ π Who has seen a ticket
- β³ π Reading long tickets
- β³ β Splitting tickets
- β³ β Selecting several tickets
- β³ ποΈ The folder pane
- β³ π½ Just my tickets, or no closed ones
- β³ π οΈ Snoozing tickets β Developer Guide
- β³ π₯ Collision detection
- β³ β±οΈ Time tracking
- β³ π Case reports - a ticket and its work as one PDF
- β³ π Scheduled work in your own calendar
- Problem Management
-
Tasks
- β³ π οΈ Task board and subtasks β Developer Guide
- β³ π§βπ€βπ§ People on a task ("Involved")
- β³ π Repeating tasks
- β³ π’ Moving a task between companies
- π Projects
-
Assets
- β³ π’ Moving an asset between companies
- β³ π Shared asset locations
- β³ π§βπΌ Assigning assets to analysts
- β³ π Warranty and lease alerts
- β³ π Leases
- β³ π Saved table views
- β³ π¨οΈ Recording anything, and importing it
- β³ π§© Asset type layouts
- β³ π Inventory freshness
- β³ π Linked configuration item
- β³ π Connected assets
- β³ π Asset review
-
β³ π·οΈ QR asset labels
- β³ π οΈ QR asset labels β Developer Guide
- β³ π Asset label designer - design (#229)
- β³ π· Asset scanning β Developer Guide
- β³ π οΈ Asset tag numbering β Developer Guide
- β³ π οΈ Asset reconciliation β Developer Guide
- β³ π οΈ Reconciliation, tags + labels - review (#164)
- β³ π Who holds what, and handover documents
- β³ π₯οΈ The inventory agent (PowerShell)
- β³ ποΈ Proxmox VE servers
- β³ βοΈ VMware Cloud Director servers
- β³ πͺ Hyper-V and Failover Clusters
- β³ π Linking equipment to tickets
- β³ βοΈ Follow-up tasks on a ticket
- Knowledge
- Change Management
- Calendar
- Morning Checks
- Reporting
- Software
-
Forms
- β³ π¨ The form designer β Developer Guide
- β³ π Layout & the grid β Developer Guide
- β³ ποΈ Collections β grouping submissions
- β³ π Submissions as PDFs
- β³ β‘ What happens next β a form's own actions
- β³ π οΈ Sections & conditional logic β Developer Guide
- β³ π οΈ Lookup fields β Developer Guide
- β³ π‘οΈ Catalogue request approvals
- People
- Starters & leavers
- Domains
- ποΈ Files
- Contracts
- Service Status
- π Notifications
- π¨ War Room
- Self-Service Portal
- LMS
- Process Mapper
-
CMDB
- β³ π οΈ CMDB β Developer Guide
- β³ π οΈ Impact analysis β Developer Guide
- β³ π οΈ Data quality β Developer Guide
- β³ π Linked assets
- β³ π Linking an asset to its CI - design (#201)
- β³ π Discovery and redundancy-aware impact - design (#199)
- β³ π οΈ Relationship wording - review (#297)
- Network Mapper
-
Workflows
- β³ π οΈ Workflow engine β Developer Guide
- β³ π οΈ Workflows for tasks β Developer Guide
- β³ π οΈ Workflow notes on a ticket β Developer Guide
- β³ π οΈ Workflow category routing β Developer Guide
- β³ β° Time-Based Triggers
- β³ πͺ Webhooks
- β³ π¬ Webhook Message Formats
- β³ π HTTPS Certificates & CA Bundles
- β³ π οΈ SSL Verification β the Global Setting
- β³ π Workflow & Webhook Pitfalls
- Issue trackers (Jira, Azure DevOps)
- π‘ Zabbix (monitoring)
- π¬ Microsoft Teams alerts
- π 3CX (phone system)
-
System
- β³ π οΈ Preferences β Developer Guide
- β³ π§Ή Maintenance
- β³ π Finding people in the Analysts list
- β³ πͺ When an analyst leaves
- β³ π οΈ System β Branding β Developer Guide
- β³ π©Ί Page health (D019) β Developer Guide
- β³ β Feature Bingo
- β³ π·οΈ Cost centres
- β³ π Chart of accounts
- β³ π· Photo Album
- β³ Demo Data
- β³ π οΈ Demo Data β Developer Guide
-
Overview
- β³ π Progress tracker
- β³ Concepts & vocabulary
- β³ Email routing & mailboxes
- β³ Settings: global vs per-company
- β³ Users & self-service
- β³ Staff cross-company access
- β³ One company supporting another
- β³ π’ One board across every company
- β³ Worked examples
- β³ Pitfalls & gotchas
- β³ Scope: what it's for
- β³ π οΈ Developer Guide (make a module multi-company)
- β³ ποΈ Case study: CMDB (a linked graph)
- β³ π§ͺ Test harness (prove it's isolated)
- What this is
-
π Bugs resolved
- β³ π Small fixes in 5.1.0
- β³ π CMDB relationships read backwards (5.1.0)
- β³ π #301 CSAT delay was never applied
- β³ π #281 Comments imported from Jira never arrived
- β³ π #288 A change failed to open with Enforce approvals on
- β³ π Long non-Latin articles never got an embedding
- β³ π« #280 Email lookups scanned the whole table
- β³ β #266 Dragging a task told nobody
- β³ π #255 Article previews showed HTML codes
- β³ π #252 A link to a Knowledge article did not open
- β³ π #254 PDFs could not print Polish
- β³ π #250 Clicking a folder left the open article on screen
- β³ π« #260 The dashboard cog did nothing
- β³ π« #248 A department rule never matched on four routes
- β³ π A directory account could be matched to someone else
- β³ π« #244 Reply went to the assigned analyst
- β³ π Mailbox sign-in was not checked
- β³ π Four weaknesses around signing in
- β³ π A lookup answer could name any record
- β³ π« #227 A mailbox could not be deleted
- β³ π« #226 A picture on a note could not be closed
- β³ π» #222 The Assets page never loaded in 4.3.0
- β³ βοΈ #214 A "contains" condition did not match capitals
- β³ βοΈ #216 A workflow email from a chosen mailbox always failed
- β³ π³ The Docker image was missing PHP extensions
- β³ π A failed DNS lookup read as a missing record
- β³ π A link could change data
- β³ π Access outlived its removal
- β³ π Knowledge articles could run scripts
- β³ π Knowledge writes ignored permissions
- β³ π Company boundaries (Oct 2026)
- β³ π Smaller gaps (Oct 2026)
- β³ π Escaped text could leave its attribute
- β³ π Task descriptions were not cleaned
- β³ π Task documents ignored company scope
- β³ π Repeating tasks ignored company scope
- β³ π¬ #183 Mailbox checks overlapped
- β³ π #188 Transfer lock shown off when unknown
- β³ β #184 Subtask names and Overdue
- β³ π§© #186 Teams: the buttons did nothing
- β³ π Text in a change could run script
- β³ π AI settings changed without the AI permission
- β³ πͺ #178 Deleting an analyst failed
- β³ π« A team with no departments showed 0 tickets
- β³ π Projects: adding a phase did nothing on Save
- β³ π Leavers could still sign in
- β³ πΌοΈ Logo and courses broke on Apache with PHP-FPM
- β³ π’ Chat tickets ignored your ticket numbering
- β³ π Dates shown as a dash, or in server time
- β³ π Assets β Users showed people from other companies
- β³ π Restricted analysts could read other modules' data
- β³ πΌοΈ Replies with a picture in the thread failed to send
- β³ π Reply attachments never reached the customer
- β³ π οΈ Outbound email attachments β Developer Guide
- β³ π A global SSO provider was missing from the portal
- β³ π Behind a proxy, the SSO redirect said http
- β³ βοΈ The portal tagline moved when you saved it
- β³ π¨ The portal settings screen forgot what you saved
- β³ π‘οΈ The approvals inbox said "Error" and nothing else
- β³ π A table's answers were missing from the PDF
- β³ β A single-select column let you tick every option
- β³ π The portal ignored a form's field widths
- β³ π The tasks board stopped taking clicks
- β³ ποΈ #121 The index list is out of date after upgrading
- β³ π #133 The calendar subscription was empty
- β³ π #131 Tasks always reopened on the board
- β³ π₯ #129 Every page returned HTTP 500 after upgrading
- β³ π³ #127 A PHP warning above the System page
- β³ π #126 Notes stamped with the server's clock
- β³ π Storing every date in UTC
- β³ πͺ The portal was down for everyone signed in
- β³ βοΈ #120 Workflow notes could never be written
- β³ βοΈ #123 Three errors when running Database Verification
- β³ π #122 The description box was a stub in the corner
- β³ π£ Demo data deleted real accounts
- β³ π #117 Sign-in redirected to the wrong address
- β³ π¨ #108 The priority dot was invisible
- β³ β±οΈ #116 Time logged from the right-click menu
- β³ π #114 API keys refused by our own guard
- β³ ποΈ #110 Assigning a task told nobody
- β³ πͺ #107 Signed out while still working
- β³ π #103 "Share with Requester" reached nobody
- β³ π #102 Search found nothing for hyphens
- β³ πͺ #101 Source code editor opened behind
- β³ βοΈ #88 Subtasks could not be ticked off
- β³ π» #84 Asset deep link selected nothing
- β³ π« #79 A new ticket arrived with no status
- β³ π§ #79 A ticket from email did not say so
- β³ π #78 Bell opened to nothing
- β³ π¬ #77 Mail only collected from Inbox
- β³ π #74 The default password could not be changed
- β³ π¦ #70 Renaming an impact level
- β³ π€ #67 App-only mailboxes could not send
- β³ π #45 Verify only ever worked for Microsoft
- β³ π #45 IMAP reported as not authenticated
- β³ βοΈ An email template stopped escaping itself
- β³ π The portal dashboard showed the wrong time
- β³ π’ The folder said 99 and the list showed 96