PageOutline
L'idée de la multi-entité est de fournir un GLPI permettant de segmenter la gestion des parcs tout en permettant une consolidation facile des données des différents parcs.

Cela peut-être intéressant pour une entreprise dont la gestion est hiérarchique et où les personnes doivent avoir une vision du parc à différents niveaux.

L'idée de la multi-entité est d'ajouter une couche supplémentaire pour créer des ensembles avec des droits qui leur sont propres. Ces ensembles s'appellent des entités. Ces ensembles peuvent être classés par lieu (le bâtiment A, le bâtiment B...) ou par service (comptabilité, commercial...) ou par hiérarchie (cadres, employés...) ou par tout autre classement.

Par défaut, cette version s'installe avec une entité générique, appelée entité racine. Cela ressemble à la partition d'un disque où le disque dur a une seule partition logique par défaut et où il est possible de diviser cette partition en plusieurs disques logiques. Cela ne change rien pour quelqu'un qui ne voudrait pas utiliser cette fonction, il existe simplement une couche au-dessus des autres qui donne une plus grande lattitude pour moduler le parc informatique, et en simplifie la gestion avec un moteur de règles.

Evolutions de la partie gestion de parc¶

Retrouvez la documentation technique sur la multi-entités.

Authentification¶

Modifications dans la partie LDAP¶

La version 0.68.3 permettait de déclarer un seul annuaire LDAP. Avec l'arrivée de la 0.70, ce nombre n'est plus limité.
Le script de mise à jour va donc :

• créer un nouvelle table pour la gestion des annuaires (glpi_auth_ldap)
• transférer les informations de l'annuaire déjà existant (s'il existait) depuis la table glpi_config à la nouvelle table glpi_auth_ldap

Attention : si vous avez un annuaire Active Directory, il faut bien vérifier que, dans sa configuration, le champ login ait bien la valeur "samaccountname" (en minuscule, c'est important).

Cinématique d'authentification¶

Désormais, GLPI est capable de s'interfacer avec plusieurs annuaire LDAP, ainsi que plusieurs serveurs POP/IMAP.

Une nouvelle notion de méthode d'authentification a été mise en place : dès qu'un utilisateur s'est authentifé, on stocke en base le type d'authentification réussie (LDAP, POP/IMAP, CAS, INTERNAL) ainsi que l'identifiant du serveur utilisé dans le case de LDAP et POP/IMAP.

Lors d'une authentification GLPI effectue les actions suivantes :

• si l'utilisateur ne s'est jamais identifié :
  • GLPI essaye de l'authentifier sur les n serveurs POP/IMAP à la suite. Si l'authentification réussie, la procédure de vérification est arrêtée.
  • GLPI essaye de l'authentifier sur les n annuaires LDAP à la suite. Si l'authentification réussie, la procédure de vérification est arrêtée.
  • si aucune authentification n'a réussi : l'utilisateur est rejeté
  • si une authentification a réussie, le type de méthode et l'identifiant du serveur est stocké en base, avec les informations de l'utilisateur
• si l'utilisateur s'est déjà authentifié auparavant :
  • GLPI reteste sa dernière méthode d'authentification
  • si l'authentification échoue, GLPI reteste toutes les méthodes, comme si c'était la première connexion de l'utilisateur

Il est possible de modifier manuellement la méthode d'authentification d'un utilisateur (non recommandé) en utilisant l'onglet 'synchronisation' de la fiche utilisateur de GLPI.

La documentation technique de la partie authenfication est disponible ici.

Création des entités¶

Le script de migration crée une entité racine.

Migration¶

Lors de la mise à jour :

• tous les utilisateurs sont affectés statiquement à l'entité racine.
• toutes les machines sont affectées statiquement à l'entité racine.
• la règle d'affectation des machines qui s'appelle 'root' est crée : elle permet, par défaut, d'affecter toutes les machines à l'entité racine. Cela permet de garder un fonctionnement aux anciennes versions.

Réaffectation¶

• il est possible de réaffecter les utilisateurs à une ou plusieurs entités, de manière statique ou dynamique
• à l'heure actuelle, il n'est pas possible de réaffecter une machine à une autre entité que l'entité racine sauf en executant des requêtes Mysql directement dans la base de données mais cela nécessite un minimum de connaissance en language Mysql

Création de règles¶

Un moteur de règles générique a été implémenté afin de pouvoir adresser les problèmatiques d'affectations (entre autre, mais pas exclusivement).
Vous pouvez trouver de la documentation technique sur :

• Spécifications techniques du moteur de règles génériques
• Documentation technique sur le moteur de règles
• Les règles d'affectation d'utilisateurs à des entités
• Les règles d'affectation des machines à des entités

Règles d'affectation des utilisateurs¶

Il existe 2 types de règles d'affectations :

• règles d'affectation statiques : la règle a été définie pour un utilisateur donné par l'administrateur
• règles d'affectation dynamiques : la règle est définie en utilisant le moteur de règles. Son exécution est automatique et ne nécessite aucune action de l'administrateur

Attention : ne pas oublier de supprimer l'affectation à l'entité racine qui a été faite par le script de migration . En effet, si vous ne le faites pas, l'utilisateur aura à le fois le profil que vous allez définir, plus l'appartenance à l'entité racine !

Une règle est composée de :

• un nom, une description et un rang
• une liste de critères (extensibles)
• 3 actions
  • assigner une entité
  • assigner un profil
  • droit d'accès récursif oui/non

Il est important de noter que :

• le moteur ne s'arrête pas après la première règle vérifiée
• il est possible d'affecter plusieurs profils/entités à une personne

Points importants concernant les règles d'affectation des utilisateurs¶

Pour qu'un utilisateur puisse accéder à une entité, il faut qu'il matche :

• soit une règle qui donne affectation à une entité et affectation d'un profil
• soit une règle qui donne affectation à une entité ET une autre qui donne affectation d'un profil

Si une règle indique juste l'affectation d'un utilisateur à une entité, alors le profil par défaut sera appliqué automatiquement pour celle-ci.

Il est possible de combiner les 2 types de règles :

• une règle A définissant l'accès à une entité 1
• une règle B définissant l'accès à une entité 2
• une règle C affectant un profil P1 à l'utilisateur
• une règle D définissant l'accès à l'entité 3 avec le profil P2

Le moteur va exécuter les règles dans l'ordre suivant :

• affectation à l'entité 3 avec profil P2
• affectation à l'entité 1 avec profil P1
• affectation à l'entité 2 avec profil P1

Règles d'affectation des machines¶

Les machines sont affectées automatiquement à une entité via une règle.

Une règle est composée de :

• un nom, une description et un rang
• une liste de critères (extensibles)
• 1 actions
  • assigner une entité

Il est important de noter que :

• le moteur s'arrête après la première règle vérifiée
• l'ordre d'exécution des règles est important
• il faut optimiser l'ordre d'exécution des règles en fonction du nombre de machines qui vont remonter (mettre en premier les entités qui auront le plus de machines, pour améliorer les performances du moteur de règles)

Règles d'affectation des logiciels à une catégorie¶

Avec la version 0.70, il est désormais possible de grouper des logiciels par catégories afin de simplifier l'affichage dans la liste des logiciels d'un ordinateur.

• Spécification du groupage des logiciels par catégorie.

Multi-entités et séparation de droits¶

Avec la gestion multi-entités, certains droits on été séparés en 2 :

• gestion globale : ne sont pas liés à une entité
• gestion locale : liés à une entité

Multi-OCS¶

Depuis la version 0.70, GLPI est capable d'agréger les données de plusieurs serveurs OCS.
Les spécifications techiniques du multi-OCS sont disponibles ici.

Modifications dans l'import OCS¶

Un nouveau script d'import et synchronisation des machines depuis OCS a été développé. Sa documentation est disponible ici.

Certains modifications ont été introduites, quant à la procédure d'import depuis OCS :

• modification des remontées des écrans (meilleure gestion des écrans, des ordinateurs avec plusieurs écrans, etc...)
• possibilité de changement d'état automatique d'un matériel lors d'une connexion/déconnexion
• remontée des clefs de la base de registre Windows
• remontée d'informations administratives depuis OCS
• choix du type de licenses lors de l'import
• changement de la gestion des périphériques connectés à un ordinateur
• remontée des logiciels avec leurs versions
• liaison automatique d'une machine remontée par OCS et saisie manuellement dans GLPI
• pas de historique logiciel lors d'un changement d'OS ou de Service Pack (car dans ces cas on peut assister à une désinstallation/réinstallation de centaines de logiciels)
• possibilité de choisir séparément l'import ou non des commentaires pour les écrans et les logiciels

Import et synchronisation LDAP dans la GLPI 0.70¶

Un nouveau script d'import et de synchronisation LDAP a été développé. Sa documentation d'utilisation est disponible ici.

Il est maintenant possible de :

• importer en masse des utilisateurs depuis un annuaire
• synchroniser en masse des utilisateurs depuis un annuaire
• filtrer les utilisateurs à importer ou synchroniser en utilisant un filtre LDAP. Cette fonctionnalité est disponible via l'interface web GLPI ou en ligne de commande par le script

Les spécifications de l'import et la synchro LDAP sont disponibles ici.

Restrictions¶

Un nouveau menu a fait son apparition dans la configuration générale : restrictions. Il rend possible certaines restrictions lors d'un ajout manuel sur la gestion des :

• téléphones
• licenses
• moniteurs
• imprimantes
• périphériques

On peut indiquer si, lors d'une création manuelle, on a :

• aucune restriction : on peut donc choisir le type de gestion (unitaire ou globale)
• une gestion unique : la gestion d'un moniteur/imprimante/license/téléphone/périphérique entré à la main sera en mode unique
• une gestion globale : la gestion d'un moniteur/imprimante/license/téléphone/périphérique entré à la main sera en mode globale

Les matériels provenant d'OCS utilisent les options d'import définies dans la configuration du mode OCSNG.

Evolutions de la partie Helpdesk¶

Interface post-only¶

Interface Admin (helpdesk.php)¶

• Champs ajoutés : Titre
• Impact de la gestion des entités : Les champs auteurs, mes matériels, attribuer présente une liste d'éléments appartenant à l'entité encours
• Le ( ?) ouvre directement la fiche de l’auteur (administration > utilisateur.)

Interface suivi ticket¶

• Ticket ouvert par : l'entité et le nom de l'utilisateur glpi qui a ouvert un ticket pour un auteur différent est historisé dans le détail du ticket à coté de l'heure d'ouverture (ex : Ouvert le: 2007-05-15 18:26:00 par M... M... (Entité Racine)) - pour les tickets repris de la 0.68.3 cette information est initialisée par le champs "auteur"

• Planification d'un suivi : Un statut a été ajouté à cette planification, trois valeurs possibbles (fait, à faire, information, cette information apparait ensuite dans le suite au dessous des dates et heures de planification.

• Document(s) associé(s) : Pour l'ajout à un ticket de document déja uploadés, ajout d'une liste déroulante "Origine document" permettant de filtrer un seconde liste deroulante qui présente les documents ayant une origine identique à celle selectionnée.

Planning¶

il est maintenant possible de filtrer le planing par groupe ou par auteur

Statistiques¶

Statistiques Globales : Pas de changement
Statistiques Par ticket :

• La notion d'utilisateur est remplacée par celle d'auteur
• Ajout du filtre par "receveur" il s'agit de la personne qui crée le ticket (champs ajouté dans la table glpi_tracking), à la migration le receveur 0.68.3 => 0.70, le receveur est initialisé par le champ auteur
• la notion d'entreprise est remplacer par celle de "fournisseur"
  Statistique par intitulés : Pas de changement

Règle métier¶

• le gestionnaire de règles disponibles dans le Version 0.70 permet de définir des règles métier, ces règles permettent entre autre d’assigner automatiquement un ticket, à un groupe, un technicien en fonction de différent paramètre de la fiche de l’auteur ou du matériel sélectionné.