Présentation

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 hierarchique et où les personnes doivent avoir une vision du parc à différents niveaux.

Si on considère la hierarchie suivante :

          EM
   EA            EB
EA1   EA2     EB1   EB2

Un utilisateur pouvant être rattaché à plusieurs entités avec des droits différents.
Ces droits pouvant être être conservés sur les entités filles ou non.

Mise en place - Les problèmes les uns après les autres

Entités

C'est une nouvelle table (glpi_entities) basée sur les dropdowns hierarchiques pour avoir la notion d'arbre.

Physiquement l'entité 0 est l'entité mère mais elle n'a pas d'existence physique dans la DB. _->Pourquoi ? Ou rattacher les utilisateurs globaux (ceux qui auront le droit des gérer les entités, de sortir des statistiques globales, etc..) ? Ou rattacher les modèles globaux ? L'EM peut être une entité réelle. _

-> Pour pouvoir définir des infos supplémentaires dans les entités il est nécessaire de créer une nouvelle table pour stocker les datas / config

Les liens vers cette table seront toujours nommés : FK_entities

  • Possibilité de génération automatique de la hierarchie : champ entité + séparateur OU hierarchie dans LDAP
  • Découplage config globale / config entité

Utilisateurs

Ils ne changent pas. La notion d'utilisateur actif est juste déplacé dans le lien User / Profil / Entité.

Lien User / Profil / Entité

Dans la table glpi_users_profiles ajout des champs :

  • entity : lien entre l'entité et le profil (à l'update et par defaut -> 0)
  • recursive : droit recursif (à l'update et par defaut -> 1)
  • active : lien actif : est-ce nécessaire ? un lien inactif ne doit pas exister dans la DB
On a 2 types d'association.
  • Les associations figées dans la DB (pas de soucis).
  • Les associations dynamiques basées sur des règles dans le cas de l'utilsiation d'une source externe :
    • Besoin de déterminer l'entité : un jeu de règle (peut-être chargement automatique depuis LDAP ?? )
    • Besoin de déterminer le profil : champs : field / value - profile - recursif
    • au login : check des critères et attribution auto du/des droit(s)

Dropdowns

La plupart des dropdowns sont globaux à toutes les entités.

Seuls glpi_dropdown_locations et glpi_dropdown_netpoint sont spécifiques.

Le champ FK_entities est donc ajouté à ces tables.

Cas des fabricants : Ce sont les entreprises de la 0.68.2 mais cela ne fonctionne pas pour une gestion globale -> copie des données dans une nouvelle table glpi_dropdown_enterprises

Elements inventaire / Gestion

Ils sont tous spécifiques à une entité -> ajout du champ FK_entities.

Dans l'edition de l'élément les dropdowns spécifiques doivent être limités aux éléments de l'entité active.

En cas d'ajout d'élément quelle entité prendre si plusieurs entités actives ? -> besoin d'une entité de travail.

Outils

Gestion globale de KB / FAQ

OCSNG LINK

Lien entité / OCSNG sur TAG.

Champ TAG dans table glpi_entities ? cas de l'entité 0 ? -> détermination automatique depuis le LDAP ?

Config d'importation globale.

Si changement tag au moment de l'importation -> transfert machine

Possibilité d'utiliser plusieurs serveurs OCS

Extrait : http://www.glpi-project.org/forum/viewtopic.php?id=5169

Que l'on importe une machine de tel ou tel serveur peut importe il faut juste savoir d'où on l'a récupéré.

Le lien OCS GLPI est pour le moment codé comme ceci :
GLPI_ID / OCS_ID
il suffit d'ajouter : OCS_SERVER_ID définissant depuis quel serveur la machine est importée.

L'affectation d'une machine à une entité se fera via le TAG OCS car cette information est là pour ca du coté OCS.

Le codage des serveurs c'est juste dans le cadre actuel : NOM / IP / login / password
les options de config d'importation étant globale à tous les serveurs OCS.

Authentification

Possibilité de définir plusieurs sources d'authentification.

Stockage de l'auth utilisé par le user dans la table glpi_users pour ne pas tout retester a chaque fois.

Définition des liens dynamique : entité / user ( / profil ? ) aussi fonction de la source utilisée.

Configuration

Affichage recherche par defaut : Gestion par le super Admin du GLPI + modif par personne.

Comment définir la notion de super admin du GLPI ?

Le super-admin est un utilisateur ayant des droits spécifiques:
  • Création / Modification d'entités
  • Gestion des données globales (voir ci-dessous)

Que faut t'il passre en gestion globale et en gestion locale ?

L'objectif du multi-entité est de pouvoir gérer de manière centralisé plusieurs services ou entreprises. Celà implique donc un référentiel de documents et de statistiques commun.

  • Méthode d'authentification -> globale avec règles d'affectation aux entités
  • Mailing ? globale ou locale ?
  • Type de documents -> globale -> modif du driot dans profil
  • Liens externes protocolés ?
  • Config générale + affichage -> globale
  • OCSNG -> globale (ou locale selon l'organisation OCS en place)

Droit de config locale remise en question. Les droits de config meme si dans les profils peuvent servir à définir les droits de super-admin ?

Transfert de machines

Le transfert de machine peut être aussi simple qu'un transfert d'entité, de lieu et d'utilisateur et de responsable.
Ca peut également être un vrai casse tête si l'on s'attaque aux données financières. Celà a-t-il un sens? Oui s'il s'agit de départements d'une entreprise avec une comptabilité unique. Non s'il s'agit d'entités avec des gestions séparées. Dans ce dernier cas il faut donner une valeur comptable au transfert !
De la même manière les données de support doivent-elles être conservées ?
D'autre part le transfert d'une machine d'une entité à une autre (tout comme d'un lieu à un autre) devrait-il supprimer automatiquement les liaisons réseaux?

Il ne nous appartient pas de prendre ces décisions. La fonction principale à offrir est de passer une machine d'une entité à une autre. Si ce passage implique pour des raisons de cohérence des données (et par conséquent de logique de gestion du parc) la suppression de telle ou telle données, elles devront être supprimées (a condition d'en avertir l'utilisateur).

  • attention * un transfert peut être provisoire (prêt entre entités par exemple) et pour la gestion du helpdesk il faut pouvoir garder l'intégralité des historiques l'impératif technique est une mauvaise raison.

Questions en attente

Moyo : Important : les questions et remarques doivent être détaillées et non anonymes sinon on ne va pas s'en sortir

JmD : Remarque c'est pas difficile de savoir qui écrit, il suffit d'observer le ton et de compter les points d'exclamations...
fdu: c'est malin comme réflexion !

fdu : pas d'accord pour le Tag OCS , c'est juste une possibilité donc doit être paramétrable .

D'autant plus que l'affectation d'une machine à une entité est un acte lourd de conséquence. Il n'est pas question de mettre le bazard parce qu'il TAG OCS a changé ou n'est pas défini.

fdu : pb fonctionnel , l'import ne devrait pas être lié à la version OCS .
-> proposition pour versions futures , modulariser l'import, avec type de base et modules d'import (OSSIM ou OCS ou autres ...)

D'autre part la question du Multi-OCS doit être conceptuellement séparée de la notion du multi-entité. (fdu : pourquoi ? )
Même si la gestion du multi-entité nécessite au préalable le multi-ocs !

proposition: avoir plusieurs occurences de config et ajouter le champs FK-entities dans la table config , à la création d'une entité elle hérite de la config de l'entité mère.
-> ca veux dire quoi concretement ?
fdu : réponse , c'est un peu différent de la notion de gabarit dans le sens , si je relie une base OCS a une entité , les entitées étant hiérachisée , si une entité possède des entitées filles , par defaut la base OCS liée à une entité fille est celle de sa mère , sauf si je change sa config et qu'elle a sa propre base.

Mon problème est que si j'ai un pool de bases OCS , que je ne peut pas gèrer les TAG OCS, comment lier les données importées aux entités , sinon en liant les bases OCS aux entités ? pour moi une entité est un élément de gestion et non une donnée issue de mes inventaires.

je crois que quelqu'un a suggéré dans ce cas de considérer plutôt la notion de domaine que le tag , mais dans ce cas il faudrai ajouter la notion de domaine(s) de l'entité. c'est une autre piste.

chacawaca : la notion de domaine est trop vague pour basé l'entité dessus, tu peux avoir + d'un domaine dans une même entité, et tu peux avoir le même domaine sur plusieurs entités, et pour le TAG OCS, il peut être défini manuellement, donc je ne vois pas le problème de gérer les entités selon le TAG OCS.

mais parce qu'on peut avoir n'importe quoi dans le tag ocs, que l'on peut avoir plusieurs champs type tag dans OCS , et que ceux qui gèrent OCS peuvent ne pas être ceux qui gèrent GLPI.
la seule parade si on choisi le tag ocs, serait de dupliquer les bases ocs pour y gerer en batch le tag ocs, et du coup on pers la fonction "temps réel", notammant pour portables qui partent dans la nature le jour même de leur configuration / affectation .

Bug à la noix de Tsmr

Pour test : Création de 3 entités en plus de l'entité racine, et attribution de users dans chaque entité avec différents profils et glpi super-admin de toutes.

  • Loggué en tant que super-admin uniquement d'une entité spécifique :

-> Je vois la liste des users de toute les entités.

-> Je peux modifier les entités dont je ne suis pas super-admin et changer les attributions d'utilisateurs

RÉPONSE : Normal cette partie sur les droits n'est pas finie. Il faut définir des droits manquants (entités etc etc)

  • Loggué en tant que glpi ( droits sur toutes les entités)

-> Je change d'entité active avec le dropdown sur la droite (showProfileSelecter) et je bascule sur une autre entité : je vois toujours tous les items et non pas uniquement ceux de l'entité sélectionnée.

RÉPONSE : tu vois tous les éléments des entités définies.
L'entité active ne sert qu'au moment des ajouts d'éléments et pour d'autres actions spécifiques. Mais on peut faire en sorte de faire autrement.

  • L'affichage en général :

-> Les entités ne sont pas personnalisables dans Administration, Recherche

RÉPONSE : Normal pas encore fait

-> Si on utilises les flèches de déplacement depuis une entité X -> on ne peut pas naviguer sur l'entité 0

RÉPONSE : Normal l'entité racine est vraiment spécifique. En particulier pour pouvoir utiliser GLPI en mode non multi-entités

-> il manque un espace entre le showlist et le printpager sur la page des entités (surement parceque la modif massive n'est pas active)

Where is the English Version ????
There is no english version of this page. You could find informations here http://glpi-project.org/spip.php?article316