GLPI Dictionary Import: XML Files for Hardware Dictionaries

GLPI dictionary import: how to load hardware dictionaries in one pass instead of a week of clicking

The focus keyword of this article is GLPI dictionary import. If you landed here, you’ve already opened the “Rules” section in GLPI and realized that manually creating seventy manufacturers and twenty computer types isn’t work, it’s punishment.

1. Diagnosis

Look at what people usually show up with. You deployed GLPI. You ran the first inventory with the agent. You opened the computer list and found a zoo: “Hewlett-Packard” and “HP” mixed together, “Dell Inc.” next to “Dell”, and the hardware type is blank for half the servers. Sound familiar?

What comes next is classic: you go to Setup → Dictionaries, see empty dictionaries for manufacturers, computer types, monitors, printers, phones, peripherals, and network equipment, and realize you’ll have to create all of that by hand through the web form seventy times over. GLPI hardware dictionary import exists specifically to avoid this.

What you’ll get by the end of this article:

• Ready-to-edit XML files for seven dictionaries: computer types, manufacturers, monitor types, network equipment, peripherals, phone types, printer types
• An understanding of why a bare name import is half the work, not all of it
• A working way to add criteria and actions to rules in bulk, without 150 clicks
• A checklist to verify the dictionary actually picks up data during inventory

Time for the full cycle: an hour to ninety minutes, once the files are ready. Most of that time goes not into importing, but into writing the recognition logic. Importing names takes five minutes per file.

You’ll need GLPI administrator rights, access to the Rules section, and at least one inventory run by the agent, so you can see raw values from real hardware. Without that, you’ll be writing criteria blind.

2. Causes

Why hardware dictionaries turn into a problem instead of staying a quiet administrative routine.

• GLPI ships almost empty by default. A base install gives you a minimal set of types and manufacturers. A real company fleet of 40-60 models blows past that set fast.
• The agent sends raw strings, not ready categories. WMI and dmidecode return whatever the manufacturer hardcoded into BIOS/SMBIOS: “Hewlett-Packard”, “HPE”, “HP Inc.” are three different strings for one company.
• Manually creating a dictionary entry means a separate form for every single value. Open, fill in the name, save, open again. Seventy manufacturers is not a five-minute job.
• A dictionary rule (RuleDictionary) is not just a list. Every rule has criteria (what to look for in raw data) and actions (what to assign as a result). Without both pieces, the rule exists but sits idle.
• Ranking decides which rule fires first. If you don’t order rules correctly, a general “HP” rule can intercept cases that should have gone to a more specific “HP Inc. – Servers” rule.
• Entities (entities_id) in multi-tenant installations break imports. If your entity name in GLPI doesn’t match the exported file exactly, the import either fails or attaches rules to the wrong place.
• Different GLPI versions handle empty criteria differently. In some versions, a rule with no criteria is treated as “always true”; in others, it never fires. That difference is critical for the resulting behavior.

3. Recipe

Preparation

GLPI permissions: an administrator profile with access to the “Rules” section. Without this, the dictionary menu simply won’t show up in the interface.

I’ve posted an archive with ready-made XML templates here: glpi_import.zip. Inside are seven files, one per dictionary: computer types, manufacturers, monitor types, network equipment, peripherals, phone types, printer types.

%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#f8fafc',
    'primaryTextColor': '#1e293b',
    'primaryBorderColor': '#94a3b8',
    'lineColor': '#64748b',
    'fontSize': '15px',
    'fontFamily': 'ui-sans-serif, system-ui, sans-serif'
  },
  'flowchart': {'curve': 'linear', 'nodeSpacing': 50, 'rankSpacing': 50}
}}%%
flowchart TD
    A["GLPI Agent"] --> B["Raw hardware data"]
    B --> C["Dictionary Rules Engine"]
    C --> D["Criterion matched"]
    D --> E["Standard value assigned to asset"]
    C --> F["Criterion not matched"]
    F --> G["Value stays raw"]
    style A fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
    style B fill:#f8fafc,stroke:#f97316,stroke-width:2px,color:#9a3412
    style C fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
    style D fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d
    style E fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d
    style F fill:#f8fafc,stroke:#ef4444,stroke-width:2px,color:#991b1b
    style G fill:#f8fafc,stroke:#ef4444,stroke-width:2px,color:#991b1b

Treat this diagram as a map of what’s ahead. We’re currently at step C, creating rules. Everything to the right and below only works once criteria are configured correctly.

Step 1. Understand the XML structure before you load anything

GLPI’s import format is strict. Each file is a set of <rule> tags inside a <rules> root. Here’s the minimal valid block for a single manufacturer dictionary rule:

<?xml version='1.0' encoding='utf-8'?>
<rules>
  <rule>
    <entities_id>Root entity</entities_id>
    <sub_type>RuleDictionnaryManufacturer</sub_type>
    <ranking>0</ranking>
    <name>Dell</name>
    <description>Servers, PCs, laptops, monitors</description>
    <match>AND</match>
    <is_active>1</is_active>
    <comment />
    <is_recursive>0</is_recursive>
    <condition>0</condition>
  </rule>
</rules>

Here’s where it’s easy to mix things up: sub_type ties the file rigidly to a specific section of the interface. Upload a file with RuleDictionnaryComputerType into the monitor dictionary section, and the import either refuses or creates garbage in the wrong place. Mapping table:

Step 2. Fix entities_id before uploading

This is where people get burned most often. In the exported file, entities_id is stored as the entity name, not its database ID. If the entity name in the file doesn’t match yours letter for letter, the import either falls back to the root entity or throws an error, depending on the version.

# replace "Comet LLC" with the real name of your entity across all XML files at once
cd glpi_import
for f in *.xml; do
  sed -i 's/Comet LLC<\/entities_id>/Root entity<\/entities_id>/' "$f"
done

# verify the replacement went through
grep -c "entities_id" *.xml

Result: in all seven files, the entities_id string points to an entity that actually exists in your installation. If you work with multiple entities (branches, clients in a multi-tenant GLPI), split the files and assign rules to the right branches before uploading.

Step 3. Upload the file through the interface

There’s no CLI command to import rules in GLPI; this operation is strictly through the web interface. Go to the dictionary section you need, scroll the rule list to the bottom of the page, and find the “Import” button. Pick a file, and GLPI shows a preview: how many rules will be created, how many already exist with the same UUID (those get skipped).

Setup → Rules → Dictionary rules → [dictionary you need] → Import

After confirming, GLPI creates the rules in bulk. Check the ranking: the import preserves the order from the file, but if you already had your own rules in that dictionary, the new ones land at the end of the list. Rebuild the order manually right after import, otherwise more specific rules end up below general ones and never fire.

Step 4. Understand what’s missing in the ready-made files

Here’s the main catch. Open any rule you just imported, and you’ll see empty “Criteria” and “Actions” tabs. The template only gives you a name and description. It’s a house frame with no interior: the walls are up, but you can’t live in it yet.

What were those API requests even for, you might ask. GLPI doesn’t drop anything on its own here. A rule with no action just silently does nothing, and that silence can be mistaken for a bug, even though it’s expected behavior.

For a rule to work, it needs at least one condition (criterion) and at least one action. Example for the “Dell” rule in the manufacturer dictionary:

• Criterion: “Manufacturer” field (raw manufacturer) contains “Dell Inc.”
• Action: assign the standard manufacturer value “Dell”

Through the interface, it works like this: open the rule → “Criteria” tab → “Add criterion” → pick a field, a condition (“contains”, “equals”, regular expression), and a pattern. Then the “Actions” tab → “Assign standard value” → pick the result value from the dropdown (it must already exist as a dictionary entry, which is exactly why you imported names in step 3).

Step 5. Automate filling in criteria and actions via API

Clicking through this manually seventy times is the exact same pain we were trying to escape in the first place. The GLPI REST API can create RuleCriteria and RuleAction programmatically. Here’s a working script that goes through every rule in the manufacturer dictionary and adds a “contains the rule’s name” criterion plus an “assign that same name as the standard value” action:

import requests

GLPI_URL = "https://it-apteka.com/glpi/apirest.php"
APP_TOKEN = "your_app_token"
USER_TOKEN = "your_user_token"

session = requests.post(
    f"{GLPI_URL}/initSession",
    headers={"App-Token": APP_TOKEN, "Authorization": f"user_token {USER_TOKEN}"}
).json()["session_token"]

headers = {"App-Token": APP_TOKEN, "Session-Token": session}

# get all manufacturer dictionary rules with no criteria
rules = requests.get(
    f"{GLPI_URL}/Rule",
    headers=headers,
    params={"searchText[sub_type]": "RuleDictionnaryManufacturer", "range": "0-200"}
).json()

for rule in rules:
    rule_id = rule["id"]
    name = rule["name"]

    # criterion: raw manufacturer contains the rule's name
    requests.post(f"{GLPI_URL}/RuleCriteria", headers=headers, json={
        "input": {
            "rules_id": rule_id,
            "criteria": "manufacturer",
            "condition": 0,  # 0 = contains
            "pattern": name
        }
    })

    # action: assign the standard value
    requests.post(f"{GLPI_URL}/RuleAction", headers=headers, json={
        "input": {
            "rules_id": rule_id,
            "action_type": "assign",
            "field": "manufacturer",
            "value": name
        }
    })

requests.post(f"{GLPI_URL}/killSession", headers=headers)
print("Done: criteria and actions added")

This is a basic template. You’ll need to adjust the patterns for real data, because “Dell” and “Dell Inc.” aren’t the same thing in a strict comparison. For manufacturers, you’ll almost always need several alternative spellings per rule: add a second criterion with an “OR” condition manually on the criteria tab for manufacturers whose names show up differently across agent reports.

Step 6. Set ranking deliberately

GLPI checks rules in ranking order and by default stops at the first match, unless the “continue checking” option is enabled on the rule itself. That means narrow, specific rules need to sit above general ones.

Example from the computer type dictionary: if you have a separate rule for “Server (virtual host)” and a general “Server (rack)” rule, the specific one needs to be checked first, otherwise the virtual host permanently lands in the general category.

Correct order (top to bottom = higher priority):
0. Server (virtual host)  - narrow criterion by model/hypervisor
1. Server (blade)         - narrow criterion by form factor
2. Server (rack)          - general "rack" signal in the model
3. Workstation (CAD/3D)   - narrow criterion by GPU
4. Workstation            - default general rule

Step 7. Repeat for the remaining six dictionaries

The logic is identical for monitor types, network equipment, peripherals, phones, and printers. The difference is only in which criteria fields you use: for network equipment it’s device type and manufacturer from the SNMP poll, for printers it’s model and device class (an MFP is identified by the presence of a scan function in the agent’s report).

Don’t try to make all seven dictionaries perfect on the first pass. Import names everywhere, add criteria for the 15-20 most common items in your fleet, that covers 80% of real cases. Finish the rest as new models show up during inventory.

4. Verification

After setting up criteria and actions, verification takes three steps.

1. Manual test run on an existing asset:
   Open the asset → "Rules" tab (if available) → "Test rule"
   
2. Force a dictionary replay across the whole fleet:
   Setup → Dictionaries → "Replay" button
   This runs already-collected data through the updated rules

3. Run a fresh inventory:
   Run the agent manually on one machine and check the resulting
   manufacturer/type value on the asset's card

Check the GLPI logs after a bulk replay: go to Setup → Logs → filter by event type “rules”. If a rule fired, you’ll see an entry noting that it was applied, with the rules_id.

5. Troubleshooting

6. Alternatives

Importing dictionary rules isn’t the only path, but it’s exactly what GLPI’s architecture expects for hardware dictionary import.

• Manual creation through the UI, no import. Works fine for 5-10 values. Dies of boredom long before you reach seventy manufacturers.
• Direct SQL edits on the glpi_rules, glpi_rulecriterias, glpi_ruleactions tables. Faster, but easy to break data integrity if you don’t know the exact foreign key structure. Use it only if you understand the schema and keep a fresh backup handy.
• Data Injection plugin. Lets you bulk-load data via CSV with field mapping, including dictionary values. Good for a one-time migration from another CMDB, overkill for regular dictionary upkeep.
• Skip normalization entirely, work with raw values. Technically possible: GLPI doesn’t force you to use dictionaries. In practice it turns your reports and dashboards into a mess of differently-spelled names for the same manufacturer.

The focus keyword wasn’t picked at random: GLPI dictionary import via XML is the only approach that preserves ranking, UUID, and rule structure in a portable form across installations. The other options are either slower or riskier for database integrity.

7. Prevention

It only takes one thing to blow up a whole quarterly report. One forgotten ranking placeholder in the manufacturer dictionary, and suddenly half your Dell servers show up as “unknown manufacturer.”

• Backup before any bulk operation. Dump the rules, rulecriterias, ruleactions tables, and dictionary tables separately before an import or Replay.
• Monitor “raw” values. Once a month, check the assets section for how many records still show an unrecognized manufacturer or blank type; that’s your signal to add missing criteria.
• Set a policy for new hardware models. As soon as the company buys a new equipment line, add a rule for it right away, don’t wait until a hundred unlabeled assets pile up.
• Version your rules. Export dictionaries to XML after every significant change and store them with the rest of your infrastructure documentation: that’s your rollback point if an edit goes wrong.
• Test criteria against real data, not assumptions. Verify that “Dell” really shows up that way in the report, not as “DELL INC.”, instead of guessing.
• Split editing permissions for dictionaries. Don’t give every GLPI admin access to edit ranking: one careless click breaks the check order for the whole company.
• Check the dictionaries after every major GLPI upgrade. Major releases sometimes change the rules engine’s behavior silently.

Backup

Upgrades

Before upgrading GLPI to a major version: dump the rule tables, read the changelog for Rules Engine changes, and run the upgrade first on a test stand with a copy of the production database. Rollback if something breaks: restore the dump plus revert to the previous GLPI archive.

8. FAQ

Why doesn’t the hardware type get set automatically after setting up the dictionary?

Most often because the imported rule has no criteria and actions: a ready-made XML only gives you a name and description, it’s a skeleton, not working logic. Check the “Criteria” and “Actions” tabs on the specific rule; with empty tabs, recognition never happens.

How do I check that the dictionary works correctly?

Run the “Replay” button in the dictionary section: it runs existing data through the current rules. Then check the asset cards: manufacturer and type should show the normalized value, not the raw string from the agent.

What do I do if entities_id doesn’t match my installation?

Replace the value with the exact name of your entity before uploading the file. GLPI looks for an exact text match, not an ID. You can check the correct name in Administration → Entities.

How does a dictionary rule (RuleDictionary) differ from a regular dropdown?

A regular dropdown is a static list of values picked manually when filling out a card. A dictionary rule runs automatically during inventory: it compares raw agent data against criteria and assigns the right standard value on its own, no human involved.

Can an import accidentally break existing data?

The import itself only creates new rule records and doesn’t touch existing assets. The risk shows up at the Replay step: a forced recalculation can overwrite values on assets if the criteria are configured imprecisely. Always take a backup before running Replay.

Why does the same manufacturer show up with different spellings from one vendor?

Firmware and agent versions on different hardware from the same vendor return different strings in SMBIOS: that’s a hardware quirk, not a GLPI bug. The fix: several criteria with an “OR” condition inside one rule, covering all the spelling variants.

9. What to expect

If you’ve gone through all seven steps, hardware dictionaries in GLPI stop being an empty formality and start actually working on every inventory run. New assets coming in through the agent automatically get a normalized manufacturer name and correct type, no manual card editing needed.

After that it just runs itself: once a quarter you check the list of unrecognized values and add a couple of new criteria for whatever hardware you just bought. Code built with good structure doesn’t fear a refactor, but nobody wants to go back to empty dictionaries either.

If something didn’t work after the import, leave a comment and we’ll sort it out.