GLPI : Comment créer automatiquement à partir de mails des tickets dans des entités distinctes selon l’émetteur
Je partage dans cet article ma petite expérience sur le paramétrage de l’outil de gestion de parc informatique GLPI. Ce logiciel permet de recenser l’ensemble des équipements informatiques, mais aussi les logiciels, contrats de service, consommables, fournisseurs, etc. Un outil indispensable à tout bon responsable informatique qui se respecte.
Une autre fonctionnalité clé de GLPI est la gestion des demandes utilisateurs. Au travers d’un portail, les utilisateurs peuvent grâce à un simple formulaire expliquer la nature de leur problème et créent ainsi un « ticket » qui sera traité par l’équipe informatique. Un système de notification par courriel permet à toutes les personnes impliquées d’être informées de l’avancement du dossier.
GLPI offre aussi la possibilité d’automatiser la création de tickets à partir d’un mail. Cette fonction est en général appréciée des utilisateurs qui n’ont ainsi même plus besoin de passer par le formulaire. La mise à disposition de cette fonction à une contrepartie : les utilisateurs vont renseigner potentiellement moins d’information que depuis le formulaire. Dans mon cas, je souhaitais simplement gérer des tickets « basiques ». Cette fonctionnalité me semble donc bien adaptée.
Cerise sur le gâteau, si un utilisateur répond à un mail de notification envoyé par GLPI, sa réponse ira automatiquement s’ajouter au suivi du ticket.
Mon cahier des charges est le suivant. Dans la configuration mise en place dans GLPI, chacun de mes clients est associé à une entité. Je vous renvoie vers la documentation de GLPI pour comprendre cette notion. Lorsqu’un email est reçu, le ticket créé doit être rattaché à la bonne entité. Pour déterminer quelle entité est concernée, nous allons tout simplement utiliser le nom de domaine de l’adresse mail de l’émetteur.
Voici les différentes étapes de configuration à réaliser dans GLPI. Nous verrons à la fin la « petite » subtilité qui a bien failli me rendre chèvre.
Configurer un collecteur.
Vous devez au préalable disposer d’un compte mail qui sera chargé de recevoir les demandes utilisateurs. Aller dans le menu « Configuration » puis « Collecteurs ». Cliquer sur le petit « Plus » et compléter le formulaire pour configurer l’accès au compte mail. Dans mon cas j’utilise le protocole POP en SSL pour relever la boîte mail. Voici le lien vers la documentation correspondante.
Pour automatiser l’activation du collecteur, une action automatique appelée « mailgate » est disponible. L’exécution des actions automatiques se fait lorsque quelqu’un utilise GLPI. Pour vous assurer que les mails seront traités au plus tôt, je vous conseille d‘automatiser sur le serveur par une tâche planifiée (tâche cron sous GNU/Linux) l’exécution des actions automatiques.
Nous avons donc maintenant nos mails qui sont automatiquement relevés par GLPI. Passons à l’étape suivante
Configurer la création des tickets dans la bonne entité
Pour cela, nous allons utiliser les « règles » de GLPI accessibles depuis le menu « Administration » puis « règles ». Dans la liste affichée, nous allons nous intéresser à celle nommée : « Règles pour assigner un ticket créé grâce au collecteur de courriels ». C’est ici que tout va se jouer. Vous devez pour chaque entité ajouter une « sous-règle » comme celle présentée ci-dessous.
Le critère de cette règle est basé sur la présence du nom de domaine. L’action consiste à assigner le ticket à l’entité correspondant au domaine. Pensez à bien activer cette sous-règle et à spécifier l’opérateur logiciel « Ou ».
Le petit truc important
Par défaut, GLPI est configuré pour ne pas accepter la création de tickets « anonymes ». Autrement dit l’adresse mail de l’émetteur doit être connue de GLPI ce qui suppose que vous lui ayez créé un compte. Un petit détail qui m’a mis dans un état de grande perplexité durant un moment. Je testais avec des adresses mail d’émetteur qui n’existait pas dans la base GLPI, donc pas de création de tickets. Pour lever cette limite, il faut aller dans le menu « Configuration » puis « Genéral » et sur l’onglet « Assistance ». A vous de voir bien entendu si cela est opportun dans votre cas d’usage.
Attention dans ce cas, si l’adresse mail de votre support reçoit du spam, cela créera des tickets qu’il vous faudra nettoyer.
Vous voilà prêt à répondre à tous les mails de demandes de vos utilisateurs 🙂 Il y a peut-être plus simple, dans ce cas les commentaires vous sont ouverts !
merci
Bonjour,
Tout d’abord je vous remercie pour cet article qui m’a été d’une grande utilité.
J’aimerais savoir s’ il y a une modification à faire pour la notification automatique (auto reply) lors de l’ouverture des tickets.
J’avais au départ tout les ticket ouvert à partir d’un email affecté à l’entité racine. J’ai crée une nouvelle entité (enfant) de racine et une règle pour attribuer automatiquement les tickets ouvert depuis l’email à cette entité en utilisant le doamine (i.e @domain.tld)
Les ticket s’ouvrent correctement ( j’ai des ticket sous entité racine et sous la nouvelle entité) mais les notification (auto reply) ne sont envoyés qu’aux ticket entité racine.
J’ai regardé les paramètres dans entité, règles, notifications mais je ne trouve rien.
je vous remercie d’avance
Bonjour,
pour ceux qui s’intéressent à la solution voici un lien avec la solution
http://www.glpi-project.org/forum/viewtopic.php?pid=193533#p193533
Merci Faisal pour ce retour. Je me permets de copier/coller ta conclusion:
Si je résume, si on active l’ouverture anonyme des tickets dans configuration>générale>assistance pour une sous-entité alors il ne sera pas possible d’obtenir des notifications pour les tickets ouverts par email si l’email utiliser est connu dans GLPI.
Absolument, et il est difficile d’analyser le comportement de GLPI dans ce cas même ni avec les logs ni en mode debug pour savoir pourquoi les email de notification ne sont pas envoyés. Il n’y aura pas d’erreur car c’est le comportement prévu dans GLPI.
oui