How it fits together
Every component is independently useful, and several are more than that when a second one is present. Nothing in the suite requires anything else to be installed; the couplings below are all discovered at runtime and degrade to the plainer behaviour when the other half is absent.
What changes when you install two
Section titled “What changes when you install two”| With this installed | This gains |
|---|---|
| GLPI Search | The known-error database matches ticket symptoms typo-tolerantly instead of with LIKE; the command palette’s record search stops needing whole words |
| GLPI AI | Eighteen components register tools into its registry — backup state, on-call rotas, cloud drift, vulnerability exposure, entitlement, post-incident actions; the known-error database gains an AI clusterer alongside the deterministic one |
| GLPI PDF | SOP checklists arrive as an appendix on the ticket’s own PDF; change risk assessments carry the answers that scored them; major incidents export as a record |
| Whitelabel | Notification mail, the public status page and generated service reports all carry your masthead rather than GLPI’s |
| GLPI Presence | The major-incident banner shows who holds the roles without duplicating who is here |
| GLPI Cloud | A provider plugin (Azure, OVHcloud) gives it accounts to sweep — on its own it has no HTTP client for any cloud |
| glpi_billing | Entitle has an ERPNext to read contracts and block-hours balances from |
| GLPI Nav | The suite’s twenty-odd menu entries move out of Tools, Setup and Administration into sections named for what a technician is doing |
Three patterns worth knowing
Section titled “Three patterns worth knowing”Everything hangs off core’s objects
Section titled “Everything hangs off core’s objects”There is no PluginGlpichangeChange, no PluginGlpiprojectProject and no second Problem. The
components that extend an ITIL object store their data keyed on core’s row id, which is why
search, saved searches, notifications, validation, templates, entity scoping and the HL API keep
behaving as the rest of GLPI expects — and why removing a plugin does not remove the core data it
was annotating.
The same rule applies downwards. Project dependencies are written into core’s own
glpi_projecttasklinks, the table that has carried a complete predecessor model since GLPI 9.5.4
and that no core code has ever written a row to. Business-service membership lives in GLPI’s
impact graph rather than a table of its own.
One owner per concern
Section titled “One owner per concern”Where two components could plausibly own something, exactly one does:
- GLPI PDF owns the document; other plugins own their content and contribute it through a hook. There is one branded PDF for the suite, not six that each look slightly different.
- GLPI Cloud owns everything downstream of a normalised resource row and makes no HTTP call to a cloud endpoint; a provider plugin owns auth, endpoints, pagination and throttling.
- GLPI core owns SNMP credentials and the inventory pipeline; Netscan owns what to scan and when, and its Go scanner ships no OIDs of its own — profiles arrive with the job.
- GLPI Nav owns no menu entry. It only moves the ones core already built.
Nothing leaves without being told to
Section titled “Nothing leaves without being told to”The model layer’s tenant gate is configuration, and its default permits nothing: no entity’s data reaches a provider until an administrator names that entity. Its write tools are off until switched on, none is requester-facing, and none deletes anything. Cloud credentials are read-only and the account form says so. Vulnerability matching runs against the inventory you already have — there is no probe, no agent and no credential on an endpoint.