7 - Administration


This part works exactly the same way as the inventory. You can add, modify, delete, and disable users, or export the list of displayed users in PDF or CSV SYLK

In terms of rights, by default, you have the choice of 4 profiles:

  • Super-Admin: Access to the center console of GLPI and full access to the application.
  • Admin: Access to the center console of GLPI and can change all the settings except those related to configuration.
  • Normal: Read-Only access to the center console of GLPI.
  • Post-only: Access to the GLPI Helpdesk (New Ticket / Tracking tickets / Reservation and FAQ service).

<note> Starting with version .68, all rights may be changed with the management of profiles (see below). The display over the management of users depends on the profile of the connected user. It may vary according to the profile. </note>

<note important> When you delete users in GLPI, they remain in the database until you purge them. To view the deleted users, click on the dropdown next to the small rubbish bin icon, and change to yes. This will show you a list of all the deleted users. You can then restore or purge them from the database using the options at the bottom of the page</note>


GLPI version 0.68 introduces the concept of groups. It allows users to be added into groups to assign materials and allow for monitoring of these common materials. Groups can also be used to add multiple people to a ticket's actors in one line (Requestor, Watcher or Responder), rather than entering them individually.

If you use external authentication, you can directly import your users into groups previously created in GLPI.

Groups also affects Notifications: a manager of a group can be alerted on an event trigger. You can also trigger a notification to an entire group or multiple groups by default, depending on how you organize them.

<note> displaying management groups depends on the profile of the logged on user. It may vary according to the profile. </note>


The idea of multiple entities is to allow GLPI to segment the departments while allowing easy consolidation of data from the different departments.

This may be useful for a company whose management/support is hierarchical and where people should have a vision of the departments at different levels, it can also be useful with multiple site entities

Multiple entities add another layer to create sets with rights of their own. These sets are called entities.

Example: Consider the following hierarchy:

    EA     EB
  |   |   |   |
  EA1 EA2 EB1 EB2

The parent entity (EM) has two subsidiaries (EA and EB) which have in turn two departments each (EA1, EA2, EB1 and EB2). Each entity has a view of its resources and entities affiliated with it.

  • EM has a vision of its objects and all entities and their objects.
  • EA has a vision for its own objects and EA1 and EA2 objects.
  • EA1 sees only its objects.

A user may be linked to several entities with different rights. These rights may be retained on the sub entities or not, using the recursive flag set to yes (visible in Administration, Users. Choose a user then look in the Authorizations tab). Setting the recursive flag to “no” will mean that the user can only see objects on the entity level they are placed in. Recursive set to “Yes” means they will see everything on their level, plus anything below on lower levels. Using this, one can set a user to be an admin of an upper level, but have read only permission to lower levels by setting Read only to Recursive. (Or vice versa.)

Entities can also be used to enforce existing security models. A better explanation of the kinds of models to use for Entities can be found on Wikipedia: Biba Model / Bell-LaPadula Model.

By default, GLPI installs with a generic entity, called the root entity.

From this interface, you can create new entities, modify existing entities, or delete them.

<note tip> The use of entities is only relevant if you want to have a relatively clear distinction between departments/elements (multi location sites for example). In many other cases it is preferable to use the features offered by the “groups” setting. GLPI runs just as well with only a Root Entity for a small organization as it does with multiple entities for a complex organization.</note>

<note tip> The automatic assignment of users and equipment to entities is possible through the setting of rules.</note>


It is possible in GLPI to define a set of rules to perform actions automatically.

Assigning Users

There are 2 types of rules of assignments:

  • Static allocation rules: the rule has been defined for a user by the administrator
  • Dynamic allocation rules: the rule is defined using the rules engine. Its execution is automatic and requires no action by the administrator

<note warning> There is a implicit rule which add profiles having the “Default Profile” attribut set (post-only after installation) to new users. Remember to modify this attribute if you don't want this feature.</note>

<note warning> Do not forget to delete the association to the root entity that has been made by the migration script. In fact, if you do not, the user has both the profile that you define, most belonging to the root entity </note>

A rule is composed of:

  • A name, description and a ranking
  • A list of criteria (expandable)
    • 3 actions
    • Assign an entity
      • assign a profile
      • Recursive access yes / no

<note important> the engine does not stop after the first rule is verified.

It is possible to assign multiple profiles / entities to a person </note>

Points Important rules of allocation users

For a user to access an entity, it must match:

  • a rule that gives an assignment and assign a profile
  • a rule that gives an assignment and another assignment that gives a profile

If a rule just assigns a user to an entity, then the default profile will be automatically applied to it.

It is possible to combine the 2 types of rules:

  A * a rule defining the access to an entity 1
  B * a rule defining the access to an entity 2
  C * a rule affecting a profile P1 to the user
  D * a rule defining the access to entity 3 with the profile P2

The engine will execute the rules in the following order:

  • Assigned to the entity 3 with profile P2
  • Assigned to the entity 1 with profile P1
  • Assigned to the entity 2 with profile P1

Machine Rules

The machines are automatically assigned to an entity via a rule.

A rule is composed of:

  • A name, description and a ranking
  • A list of criteria (expandable)
  • 1 operation: assigning an entity

<note important> The engine stops after the first rule verified

The execution order of rules is important

It is necessary to optimize the execution order of rules based on the number of machines that go back (to the first entities that have the most machines, to improve rules engine performance) </note>

Rules for assignment to a software category

With version 0.70, it is now possible to group by categories of software to simplify the display in the list of software on a computer.

Examples of rules are available developer wiki The rules feature also has a Test Rules function to see if the program logic will trigger on certain search strings, so you don't have to trigger it manually to check your work.


Since version 0.71, it is possible to define dictionaries.

This dictionary can contain rules that will change the values of certain data imported from OCS. At the moment, these are:

  • Name of the software
  • Software version
  • Manufacturers
  • Models (computers, monitors, printers, network, phones, peripherals)
  • Types (computers, monitors, printers, network, phones, peripherals)
  • OS (name, service pack, version)

Dictionaries are launched during the automatic processes:

  • Import OCS
  • Injection of CSV files
  • Adding a title

It is possible to launch the dictionary of the database:

  • In the form of lists of rules, click “Play the dictionary”
  • For software massivement select and choose “Replay dictionary” in the list of software

How To Use The Dictionary

The dictionary works as follows:
 * To enter the database (from OCS or plugin data_injection) pass

by the dictionary

  • The rule engine plays all the rules concerning this type of data, and wont stop at the first verified
  • Modified the data is returned by the dictionary and inserted into the database

To reapply the dictionary on an existing database, just go to the list of rules to it, and click the button “Play the dictionary.” In the case of dictionary software, it is possible to specify a manufacturer to limit the performance of the engine to it (the application on all the software is long).

<note> A script is available in the GLPI scripts (compute_dictionnary.php), which allows you to launch the dictionary from the command line. This helps overcome the problems for implementation, and offers a gain of appreciable time. </note>


If your database is consistent, you should be careful to vale heart of PHP memory_limit. Indeed, the treatments can be very long.

Software Dictionary

These rules allow to modify the information following software:

  • Name of the software
  • Version
  • Manufacturer

The use of regular expressions (regex) is used to extract the version of software from its name.

For example, for the following software:

  • Name: MyCompany MySoft v6.4
  • Version: 1
  • Manufacturer: none

It is possible to make a rule that converts the data to:

  • Name: MySoft
  • Version: 6.4
  • Manufacturer: MyCompany

Examples of rules are available on the wiki

Dictionary Manufacturers

This dictionary allows you to clean the list of manufacturers.


GLPI version 0.68 introduces the concept of profiles. It is possible to manage all of the rights of the application GLPI with profiles and associate them to users.

You can create new profiles, modify existing profiles, or delete them.

2 interfaces are configurable:

1. Simplified

This interface includes the rights associated with public help desk: Creating a ticket, ticket tracking, see the public followed (his own and those of the speakers on the tickets), tickets to see the groups, access to reservations, FAQs and change their password.

Linking materials for creating tickets: You can choose whether users can post tickets only on the material to which they are attached (in the detail of equipment) or can select the entire equipment inventory. And thanks to the selection, you can specify which type of material they may make requests for.

2. Standard

This interface includes the rights associated with the center console, and thus all its components (inventory, assistance, management, tools, plugins, administration).

  • Inventory

Access, reading, writing all the equipment inventoried. This allows you to configure, access details of equipment and management related fields.

  • General

Access, reading, writing notes on the tabs in the detail of a material, changing its password, as well as public notes on the center console.

  • Management

Access, reading, writing documents, business, financial and information materials.

  • Assistance

Access, reading, writing on the Helpdesk console.

  • Tools

Access, reading, writing about the OCS-NG reports, booking, Knowledge Base and FAQ service. NB: the knowledge base is different from the FAQ published by the fact that it shows the public and private items as opposed to the public FAQ which displays only public items.

  • Administration

Access, reading, writing about configuring GLPI.

Using profiles on the Standard Interface, one can configure a class of users with a subset of features (for example, having Contractors only see Inventory and Assistance menus with everything else set to No Access, while Volunteers see Assistance and Tools.) The Simplified Interface can only display the Homepage, Tickets, FAQ, and Notes (or less than that if set that way in profiles.)

<note warning> If you delete the profile super-admin or if you set “Helpdesk” as Default profile, access to GLPI configuration may be permanently lost. </note>

<note> The profile management display is based on the profile which the user is connected. It may vary according to the profile. </note>


Since version 0.70 of GLPI and the emergence of the concept of “entities”, it is possible to define profiles for the transfer of items between multiple entities.

This feature makes it possible to move from a single entity GLPI GLPI a multi-entity using transfers.

How to make a transfer:

  1. You must have a profile which has the right to make transfers (Administration/Profiles/part Administration)
  2. it's necessary to configure the actions made by the transfer (Administration/Transference)
  3. the profile which is going to make the transfer has to have a visibility on the old entity and on the new entity (a recursive profile since the entity root it's the simplest)
  4. You position on the entity root
  5. when on the list of machines, select those which do you want to transfer
  6. choose Tranfer and Post
  7. in Transfer Mode, you will see the list of the configurations of transfers created at the point 2
  8. select the entity in which will be transferred the material
  9. click to Transfer
  10. verify in the new entity that the material is there

Be careful : place and group will be adapted for the new entity

Data (Backup / Restore)

This area allows you to make backups of the database (“SQL Backup”).

You can also delete, restore or download the backup files.

To restore a SQL backup downloaded another GLPI, put it in “files_dumps” of your GLPI; restart your GLPI interface and restore the configuration data.

You can also generate a backup in XML format for a database. (“Save XML”).


This area lets you view and sort the history logs. The degree and the retention of logs is configurable in the menu Configuration - General - Level of logging.