You are not logged in.
Pages: 1
Bonjour,
Cela fait mainetnant longtemps que je réfléchi aux concepts GLPI et que je me creuse la tête pour trouver le meilleur fonctionnement.
Cependant je n'arrive pas à trouve la réponse à une question de "logique" GLPI sur les entités :
- Les entités sont-elles censées représenter la structure du "demandeur" ou bien du "receveur".
Pour donner mon exemple local, on utilise GLPI pour la DSI du rectorat, mais on veut étendre l'usage aux autres services, et notamment leur permettre d'intervenir sur les tickets.
Actuellement on utilise pour simplifier 2 entités filles : Etablissements et Services Administratifs.
Les utilisateurs ont les droits de post only sur l'entité dont ils sont "originaires", donc quelqu'un en étab va pourvoir faire un ticket sur établissement, et quelqu'un en service adm aura le post only sur cette entité.
Donc les entité chez nous représente "l'origine" du demandeur.
Les avantges que j'y vois :
- On sait d'où vient la personne
- On peut restreindre les catégories ITIL selon la personne qui fait la demande
Les inconvénients :
- Tous les services traitants voient tou sles tickets de toutes les entités, on ne peut cloisonner (notamment sur les tableaux de bord, ou bien sur les indicateurs au dessus de slistes de recherche) aux tickets detinés à notre service.
-> je sais que je peux restreindre les listes comme je veux selon les critères (groupe de technicien etc) mais l'affichage des gros indicateurs me parait compliqué à filtrer avec cette config/
Si on modifie l'architecture de nos entité et les habilitations pour inverser la logique, c'est à dire avoir une entité Service adm et des sous entités avec les services "detinataires" des tickets...
Avantages :
-On peut restreindre plus facilement la visibilité des tickets grace aux entités
- On peut restreindre le catalogue de service par entité
Inconvénients :
- Les utilisateurs doivent avoir des habilitations sur plusieurs entités -> Si je décide de donner des doits de post-only recursif sur l'entité mère, ils vont aussi pouvoir poseter sur l'entité mère...
- Si un ticket est ouvert dans une mauvaise entité, le système de "transfert" est assez lourd et pas très intuitif -> Sélectionner le ticket dans la liste, faire une action, "ajouter à la liste de transfert" choisir l'entité, valider...
- C'est largement plus contraignant que de tout simplement changer le groupe de technicien traitant
Bref, ca me casse un peu la tête, quels sont vos conseils ??
Merci.
Offline
Bonjour,
Clairement ce probleme dure depuis le debut et n'ai pas claire ou ne correspond pas a l'utilisation reel faite en entreprise, j'attends clairement avec impatience les retours de dev ou utilisateurs qui ont trouver comment faire grace a cette discution.
Bonne journée
Offline
L'entité c'est un peu a vous de définir
GLPI est customisable, utilisable comme vous le souhaitez, a vous de définir votre norme d'utilisation
L'entité peut représenter l'entreprise directement, des services ou autre.
les utilisateurs de base sont cloisonné dans une entité.
les technicien par défaut font du global, mais il est possible de les cloisonner également si nécessaires, via les profils ou groupe d'utilisateurs a créer vous meme.
Glpi est un outil Global et generique, c'est a vous de l'adapter a vos besoins.
Offline
Nous utilisons les entités pour cloisonner les demandeurs ... et parfois les receveurs pour une question de profils.
Les deux sont donc possibles.
En tant que collectivité d'agglo, nous travaillons actuellement sur la mutualisation de certains services (DSI, finances, etc) avec les 36 communes du territoire.
Concernant la DSI et donc l'usage de GLPI, j'ai choisis de créer 2 sous-entités principales :
- l'une est notre entités racine actuelle avec différente service interne à la collectivité (RH, Moyen Généraux) ; je vais donc descendre tout d'un niveau. Dans cette entité principale, les sous-entitiés de services dépendent plus du receveur que du demandeur
- la seconde englobera l'ensemble des communes du territoire, chacune dans sa sous-entités. Là, les sous-entités dépendront plus du demandeur que du receveur
L'entité racine sera quasimenet vide (resteront les SA et peut-être qq formulaires communs aux communes et à notre collectivité)
Ce changement important pour nous est aussi permis par le plugin formcreator qui autorise, enfin (depuis le temps que je le demandais !), d'accorder l'accès non plus selon un profil (pas très logique) mais selon des groupes ; ce qui apporte plus de souplesse.
Par ailleurs, je trouve qu'i est plus facile de gérer des groupes de techniciens (quelques comptes) que les comptes utilisateurs.
Concernant les stats, les TdB interne sont peu pratiques, nous avons fait le choix de passer par Grafana, beaucoup plus puissant
Manger un castor, c'est sauver un arbre.
Quand on est mort, on ne sait pas qu'on est mort ; c'est pour les autres que c'est difficile. Quand on est con, c'est pareil !
Offline
Pages: 1