Récuperation des demandes d'ouverture de tickets par emails

Plusieurs options :

1) A partir d'un compte pop, injecter dans GLPI automatiquement les nouvelles demandes d'interventions à intervalles réguliers.

2) A partir d'un stream sendmail, on intercepte les mails et on les redirige sur le script adhoc

Informations à récupérer :

- User (à partir de son email ou d'un tag ?) -> ie pré-remplir le ticket avec les infos contenus en db
--> Se baser sur l'email semble plus simple, si email inconnu , on met le ticket à nobody.

- Materiel (tag ?)
-->A voir pour le futur mais pour le moment on peut décider de mettre le ticket à général.

- PJ (screenshots) -> on crée autant de pj que d'élements
--> Est ce vraiment pertinent, d'autant plus qu'on risque de se retrouver avec un paquet de pj inexploitables (signatures, logos d'entreprises..)

Règles de routage :

- On match des règles de routages pour affecter automatiquement les tickets à un tech ou un groupe de tech.
--> Directement liée au business rules, pas de gestion au niveau de la mailGate.

Points à gérer :

- La problématique multi-entité
--> IL est possible d'affecter le ticket à une entité en fonction de l'entité de rattachement du user. Mais que fait-on si le user fait partie de plusieurs entités ou si le user n'est pas connu ?
Une piste à creuser : tout comme le multi-ocs, offrir plusieurs configs pour aller taper dans plusieurs comptes mails, à chaque compte mails correspond une entité, tout mail qui arrive sur cette boite est associé à cette entité.
Autre piste : Utiliser les business rules pour offrir des actions d'affectation d'entités à des tickets qui matchs certains règles, du coup on peut definir des règles par défaut ...

- Les réponses des utilisateurs à un ticket (nécessité de suivi).
--> Pour le moment ça semble trés difficile de le gérer, il faudrait pour cela matcher l'intégraliter du mail et faire la distinction entre ce qui existait déjà et l'ajout de l'utilisateur.
Le choix de ne prendre par mail que les ouvertures de tickets semble plus cohérent. Le reste du suivi se réalise via l'interface helpdesk.

ABCD33
Ne pourrait-on pas se contenter de reprendre l'intégralité du mail ? Il est à mon avis inutile d'essayer de distinguer l'ajout de l'utilisateur par rapport à l'existant. Dans le pire des cas, on peut toujours enlever tout le texte qui est quoté, mais dans ce cas il faudrait mettre l'intégralité du mail en pièce jointe.
L'idée serait juste de rechercher le numéro de ticket dans le sujet, si ce numéro correspond à un ticket existant on considère ce mail comme un suivi et non comme un nouveau ticket.
Éventuellement si le ticket est fermé on le remet ouvert.

JMD
Oui c'est une possibilité mais il est clair que l'affichage des suivis dans l'interface va être horrible et quasiment inexeploitable. Je parle même pas de la tête des mails automatique de GLPI lors qu'on aura 5 suivis déjà présents tous importés par mail qui contiendront l'ensemble des correspondances déjà échangées.. Il est là le problème.

ABCD33
Alors on reste sur l'idée d'enlever le texte quoté et de garder le message original en document joint ?

JMD oui cela me semble le mieux mais ça risque de ne pas être évident du tout à réaliser...

ABCD33
OK c'est pas marrant à faire. J'ai donc opté pour une solution nettement moins élégante, mais que j'ai vu utilisée par ailleurs dans d'autres projets.
Je positionne un tag de début et fin dans la notification envoyée à l'utilisateur, si le mail est en HTML le tag est dans un div en visibility hidden.
Quand l'utilisateur répond au mail, je supprime simplement tout ce qui est entre les tags.

J'indique dans chaque notification que l'utilisateur ne doit pas modifier le message et répondre au dessus ou en dessous.

J'ai une petite variante aussi, comme chez nous les utilisateurs ont Outlook, je supprime tout ce qui est entre "-----Message d'origine-----" et la fin de mon tag.

Le patch est disponible à l'adresse: http://ober.tempo-consulting.fr/mail-import.tar.gz