You are not logged in.
Bonjour,
notre "chef d'équipe HelpDesk" souhaiterait pouvoir visualiser l'ensemble des tickets dont il est responsable, çàd :
- les tickets affectés aux 2 "groupes" dont il a la charge,
- mais aussi les tickets affectés aux membres de ces 2 groupes.
En effet, dans notre manière de travailler, lorsqu'un technicien traite un ticket, il supprime l'affectation de son propre groupe à ce ticket.
Il se retrouve donc seul affecté au ticket.
Cela n'est visiblement pas possible : on ne peut pas créer une recherche qui permette le lister les tickets affectés aux membres d'un groupe.
Solution de contournement : j'ai créé pour lui une recherche avec l'ensemble de ses équipiers :
"Non résolus"
ET
(
Affecté à technicien XXX
OU
Affecté à technicien YYY...
)
-> ce n'est ni joli, ni pratique...
Une idée ?
Je vous remercie.
Cordialement,
Offline
Je crois que la réponse à ce post pourrait t'aider:
https://forum.glpi-project.org/post.php … qid=367229
Bonjour,
J'ai trouvé d'où venait le problème : en fait, pour améliorer le chargement des groupes de l'utilisateur, les développeurs de GLPI ont apporté une modification au fichier inc/session.class.php :
https://github.com/glpi-project/glpi/pull/5976/files
Mais, leur correction ne prend pas en compte les groupes qui sont définis dans une entité supérieure et qui sont néanmoins déclarés comme "visibles" dans les entités enfant.En reprenant le code précédent ($_SESSION['glpiactiveentities']) mon problème est résolu.
Cordialement,
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
Je crois que la réponse à ce post pourrait t'aider:
https://forum.glpi-project.org/post.php … qid=367229cmonnet wrote:Bonjour,
J'ai trouvé d'où venait le problème : en fait, pour améliorer le chargement des groupes de l'utilisateur, les développeurs de GLPI ont apporté une modification au fichier inc/session.class.php :
https://github.com/glpi-project/glpi/pull/5976/files
Mais, leur correction ne prend pas en compte les groupes qui sont définis dans une entité supérieure et qui sont néanmoins déclarés comme "visibles" dans les entités enfant.En reprenant le code précédent ($_SESSION['glpiactiveentities']) mon problème est résolu.
Cordialement,
Sico31, je te remercie pour ta réponse mais je ne pense pas que ce soit le même contexte : il n'y aucune notion d'entités dans mon "problème". Je souhaiterais juste qu'un "manager" puisse voir l'ensemble des tickets affectés aux techniciens des groupes "A" et "B", ce qui ne semble pas possible avec GLPI. On peut créer une recherche qui renvoie les tickets affectés aux groupes "A" et "B", mais pas affectés aux techniciens de ces groupes.
Offline
Et en utilisant le plugin behaviors (coportements) qui permet d'obliger l'affectation d'un ticket à un groupe ?
ainsi, ton tech' ne peut pas supprimer son groupe dans l'affectation du ticket et il peut pour autant en être aussi le tech' affecté à ce ticket.
soit : groupe obligatoire, utilisateur optionnel
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
Et en utilisant le plugin behaviors (coportements) qui permet d'obliger l'affectation d'un ticket à un groupe ?
ainsi, ton tech' ne peut pas supprimer son groupe dans l'affectation du ticket et il peut pour autant en être aussi le tech' affecté à ce ticket.
soit : groupe obligatoire, utilisateur optionnel
Cela me semble une bonne idée : pour le moment je vais passer la consigne de ne pas supprimer le groupe, puis je testerai ce plugin Behaviors. Je pense qu'il n'y ait pas d'autre solution. Et ce n'est pas une mauvaise idée de laisser son propre groupe affecté.
Merci pour tes réponses Sico31 !
Offline
Bonjour,
merci pour ce petit hack: ça fonctionne pour nous.
Symptome:
un technicien affecté a une entité ne voyait pas les tickets assignés à son groupe => ça fonctionnait portant bien pendant longtemps.
Après vérification, je comprends qu'n technicien affecté à l'entité racine et à toutes les autres par récurcivité voyait tous les tickets du groupe.
J'ai appliqué cette modification et cela refonctionne.
Merci & Devezh mat
Glpi 9.4.3
Debian Serveur Jessie
Camping car Bretagne
Offline
Cela n'est visiblement pas possible : on ne peut pas créer une recherche qui permette le lister les tickets affectés aux membres d'un groupe.
Solution de contournement : j'ai créé pour lui une recherche avec l'ensemble de ses équipiers :
"Non résolus"
ET
(
Affecté à technicien XXX
OU
Affecté à technicien YYY...
)
-> ce n'est ni joli, ni pratique...Une idée ?
Je vous remercie.
Dans votre cas je mettrais
groupe est votre groupe
OU
Technicien contient ^
Il vous suffira ensuite de trier la colonne des techniciens pour avoir la liste de leur tickets
CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6 - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)
Offline
YannD45 wrote:Cela n'est visiblement pas possible : on ne peut pas créer une recherche qui permette le lister les tickets affectés aux membres d'un groupe.
Solution de contournement : j'ai créé pour lui une recherche avec l'ensemble de ses équipiers :
"Non résolus"
ET
(
Affecté à technicien XXX
OU
Affecté à technicien YYY...
)
-> ce n'est ni joli, ni pratique...Une idée ?
Je vous remercie.Dans votre cas je mettrais
groupe est votre groupe
OU
Technicien contient ^Il vous suffira ensuite de trier la colonne des techniciens pour avoir la liste de leur tickets
Bonjour Yllen
que signifie "Technicien contient ^" ?
Je viens de tester mais je n'obtiens pas le résultat que je souhaite, c'est à dire lister les tickets affectés à un groupe OU aux MEMBRES de ce groupe (ce qui arrive si un technicien s'affecte à un ticket et supprime son groupe des affectations)
Merci à vous.
Offline