NexTool Solutions

You open the category dropdown to log a ticket in GLPI 11 and, instead of a clean name, you get a block like this: "Error using automation - 337.TYPE:INC;Group:AUTOMATION;Urgency:Very High". What should just be the category name became a line of metadata the technician has to decode every time. This is not a defect in your environment: it is GLPI itself concatenating the category's code field into every dropdown.

The problem

Every GLPI ITIL category has an optional field called code. It exists for good reasons: process numbering, a routing key for business rules, an integration parameter for an ERP or an external ticketing system. The problem is not having the field filled in - it is where it shows up. When a category has a code, the GLPI core concatenates that value onto the name in every dropdown in the interface, using the separator - . Backstage information leaks onto the screen of someone who just wants to pick "Network" or "Printer".

In practice, the more structured your code, the worse it gets. Teams that load metadata into the field (ticket type, responsible group, suggested urgency) end up with dropdowns where the actual category name is the smallest part of the text. The eye reads left to right, hits the code first, and slows down. On smaller screens the text is truncated in the middle of the code - so not even the name shows in full.

The two obvious workarounds fail. Editing the GLPI core to remove the concatenation works until the next update, when the file is overwritten and the problem returns. Clearing the code field cleans the screen but breaks everything that depended on it - rules, integrations, reports. You would trade a visual nuisance for a functional failure.

How GLPI Bug Fixes solves it

The GLPI Bug Fixes module attacks the symptom in the right place: rendering, not data. It never touches the database and it does not edit the core. Instead, it wraps the global Select2 template functions that GLPI uses (window.templateResult and window.templateSelection) and cleans the text at the source, before it reaches the DOM. The code field stays intact in the database; it simply stops appearing in the interface.

• Cleans the name and the tooltip - it removes the - CODE suffix from both the option text and the title attribute (the hover bubble), in the list and in the already selected value.
• Covers both places the category appears - the classic ticket, change and problem dropdown (itilcategories_id) and the category selection questions in the new GLPI 11 forms system (Glpi\Form).
• Deletes nothing - the code remains available for business rules, integrations and reports. It is a purely visual fix.
• Toggles per feature - the fix is an individual toggle on the Features tab; enabling or disabling it takes effect immediately, with no need to reinstall the module.
• Survives updates - because everything runs through the plugin, updating GLPI does not undo the fix.

The detail that separates a safe fix from one that breaks everything else

This is where hands-on GLPI operations experience comes in. The first version of the fix did the obvious thing: it cleaned the text of any Select2 dropdown that matched the pattern " - something". It looked right until a client reported that group names had been chopped - "N1 - Support" became "N1", "N2 - Infrastructure" became "N2". The - separator is legitimate in many names; cleaning by text pattern is naive. The fix was rewritten to be scoped by the field's identity, not by how the text looks.

For the ticket, that is straightforward: it only acts when the <select> is named itilcategories_id. In the new forms system it is subtler, because the question uses a generic name like answers_5[items_id] that serves any item (category, location, supplier). The clue is a sibling <input hidden> that declares the type. The module only cleans the text when that sibling says ITILCategory:

<!-- Ticket: the fix runs because the name is exactly itilcategories_id -->
<select name="itilcategories_id">
  <option value="12"
    title="Error using automation - 337.TYPE:INC;Group:AUTOMATION">
    Error using automation - 337.TYPE:INC;Group:AUTOMATION
  </option>
</select>

<!-- Form (Glpi\Form): only cleans if the sibling hidden is ITILCategory -->
<select name="answers_5[items_id]"> ... </select>
<input type="hidden" name="answers_5[itemtype]" value="ITILCategory">

<!-- Group: different name and no ITILCategory hidden -->
<!-- the legitimate " - " is PRESERVED -->
<select name="groups_id">
  <option>N1 - Support</option>
</select>

It is the kind of decision that only surfaces in day-to-day support: the "quick" solution breaks an edge case no synthetic test covers, but which exists in almost every real environment where groups are named by service level.

Before and after, by context

How to enable it

1. Install the NexTool plugin on your GLPI 11 (if you do not have it yet).
2. Go to Setup > NexTool > Modules and enable the GLPI Bug Fixes module.
3. Open Configure and go to the Features tab.
4. Confirm that Hide category code in dropdowns is on - it comes enabled by default after installation.

The fix takes effect the next time you open a category dropdown. There is no need to restart the service or clear the cache: the JS asset carries a version stamp that changes on its own when you toggle the feature, so the browser always loads the right version.

Who it is for (and when not to use it)

It makes sense for any team that fills in the code field of ITIL categories - whether for internal numbering, rule-based routing or integration - and whose technicians or end users pick a category daily. The more people who open tickets, the greater the clarity gain.

It makes no difference if your categories have no code filled in: with no concatenated code, there is nothing to clean. And if you want the code on screen - some teams use it as a quick reference at the service counter - just leave the feature off. That is exactly why the fix is optional.

Compatibility

• GLPI: 11.0 or higher
• Module: GLPI Bug Fixes (key fixes) - free plan (FREE)
• Plugin: NexTool 4.1.3 or higher
• Coverage: tickets, changes and problems, plus the new forms system (Glpi\Form)

Next step

GLPI Bug Fixes is part of NexTool, the module ecosystem that extends GLPI without core customization. The module is free and already in the catalog. If you would like help installing it or evaluating other fixes, talk to the team.

This content was produced with the help of artificial intelligence and reviewed by the Nextool Solutions team.