Comment configurer les notifications en évitant de se spammer soi-même

eiseli · 2009-05-15 14:49:35

Bonjour,

J'utilise GLPI 0.71 et j'aimerais affiner les notifications e-mail et là il y a un détail qui m'échappe.

Voici la configuration actuelle:
1) A chaque nouveau ticket: Technicien chargé du ticket / Demandeur
2) Pour chaque nouveau suivi: Demandeur
3) A la fermeture du ticket: Demandeur
4) A la mise à jour du ticket: Ancien technicien chargé du ticket

Ce qui m'irrite, c'est que la configuration ne tient pas compte de "qui" fait la modification qui génère le mail.

Voici les cas que j'aimerais configurer:
1) A chaque nouveau ticket: Technicien chargé du ticket (S'IL N'EST PAS LUI-MEME CELUI QUI OUVRE LE TICKET) / Demandeur (S'IL N'EST PAS LUI-MEME CELUI QUI OUVRE LE TICKET)
2) Pour chaque nouveau suivi: Demandeur (S'IL N'EST PAS LUI-MEME QUI ECRIT LE SUIVI)
3) A la fermeture du ticket: Demandeur (S'IL N'EST PAS LUI-MEME QUI FERME LE TICKET)
4) A la mise à jour du ticket: Ancien technicien chargé du ticket (S'IL N'EST PAS CELUI QUI MODIFIE LE TICKET), NOUVEAU TECHNICIEN CHARGE DU TICKET (S'IL N'EST PAS CELUI QUI MODIFIE LE TICKET)

Pour le point 4, c'est très important car actuellement si je "vole" le ticket à mon collègue, il reçoit bien un mail. Par contre, si je lui attribue un ticket, il ne reçoit pas de mail. A moins que j'ajoute à la liste également "technicien chargé du ticket". Ce qui n'est pas souhaitable, car dans ces cas-là, si c'est moi qui mets à jour le ticket, je suis carrément innondé de spam, ironie du sort, généré par moi-même...

Comment gérez-vous ces situations?

MoYo · 2009-06-04 20:55:56

via des filtres de messagerie ?

je note vos remarques sur le wiki de dev sur la partie notification pour étude.

eiseli · 2009-06-05 08:10:35

MoYo wrote:

via des filtres de messagerie ?

J'y ai pensé, mais il n'y a aucun repère dans le message qui puisse m'indiquer la cause du message (pas de header supplémentaire comme le fait bugzilla par exemple). Chez nous, tous les messages proviennent de Helpdesk@... et je ne connais aucun client de messagerie qui puisse analyser le message à une telle profondeur pour qu'il puisse détecter par qui a été généré le dernier suivi.

Donc en résumé: le plus simple c'est toujours de régler l'envoi (ou le non-envoi) de mails à la source. La possibilité de faire des tris supplémentaires au niveau de la messagerie est toujours une bonne chose, mais ne devrait pas être l'unique solution.

sbonn · 2009-07-21 11:01:31

Bonjour,

J'ai exactement la même demande des personnes utilisant GLPI dans mon service : comment éviter de se spamer, tout en recevant des mails pertinents.

Eiseli, as tu trouvé une solution ?

Afin de vous aider dans la réflexion, voici ce que j'aimerai configurer (pas tout à fait comme eiseli mais je pense qu'il s'agit exactement du même besoin en un peu plus développé) :
Pour info, nous avons un centre d'appel (pas de techniciens) qui reçoit les appel (téléphone / mail / autre) et donc renseigne des suivis sur des appels qui ne leur appartiennent pas. Dans ce cas, il faut pouvoir alerter le technicien mais pas le demandeur (qui vient de faire son suivi via le centre d'appel).
De plus, afin d'avoir des stats corrects, il faut qu'on renseigne un technicien ET un groupe (pour faire des stats par groupe et/ou par technicien). Dans ce cas, il serait souhaitable de n'envoyer des notifications à un groupe que lorsque qu'un technicien n'est pas renseigné. (pour éviter de spamer le groupe...)

1) A chaque nouveau ticket: Technicien chargé du ticket (S'IL N'EST PAS LUI-MEME CELUI QUI OUVRE LE TICKET) / Demandeur (S'IL N'EST PAS LUI-MEME CELUI QUI OUVRE LE TICKET) / Groupe chargé du ticket (Si le technicien chargé du ticket n'a pas été renseigné : Sinon, on spam le groupe alors que l'appel est affecté à un technicien)

2) Pour chaque nouveau suivi: Demandeur (S'IL N'EST PAS LUI-MEME QUI ECRIT LE SUIVI) / Technicien chargé du ticket (S'IL N'EST PAS LUI-MEME CELUI QUI ECRIT LE SUIVI)

3) A la fermeture du ticket: Demandeur (S'IL N'EST PAS LUI-MEME QUI FERME LE TICKET)

4) A la mise à jour du ticket: Ancien technicien chargé du ticket (S'IL N'EST PAS CELUI QUI MODIFIE LE TICKET) / NOUVEAU TECHNICIEN CHARGE DU TICKET (S'IL N'EST PAS CELUI QUI MODIFIE LE TICKET) / / Nouveau Groupe chargé du ticket (Si le technicien chargé du ticket n'a pas été renseigné : Sinon, on spam le groupe alors que l'appel est affecté à un technicien)

Point 4 : même remarque que eiseli. De plus, j'ai rajouté le nouveau groupe chargé du ticket car si on est obligé de changer le groupe , on est pas sensé connaitre qui va traiter l'appel. (par exemple : equipe bureautique qui ne connait pas l'équipe réseau mais qui a remarqué que l'appel leur était arrivé par erreur : "j'ai un probleme outlook" et en fait il s'agit d'une perte de connexion réseau)

Point 2 : Dans mon cas, il s'agit du centre d'appel qui renseigne les suivis lorsque les demandeurs apellent ou envoient un mail, il ne faudrait donc pas que cela envoie une notification au demandeur (vu qu'au final, c'est lui qui a fait la demande)
Enfin, j'imagine que pour ce point, le besoin est spécifique à une "hotline" qui gère un seul point d'entré pour éviter que les techniciens soient harcelé en direct.

Si jamais vous avez des questions, n'hésitez pas.
Sinon, je voulais vous féliciter pour la v0.72 qui améliore déjà beaucoup les choses ....!

eiseli · 2009-07-21 11:11:28

sbonn, désolé, non il n'y a aucun changement à ce que j'ai écrit. Comme MoYo l'a dit plus haut, ils veulent étudier le point. Pour l'instant, on fait avec.

sbonn · 2009-07-21 11:15:41

Ben on va attendre ..!
J'ai vu qu'il est à l'étude https://dev.indepnet.net/glpi/wiki/GlpiNotifications
Comme j'ai à peu pres le meme besoin que toi, je voulais simplement m'impliquer un peu même si je n'ai helas pas le temps de développer...

sbonn · 2009-10-07 12:45:32

https://forge.indepnet.net/wiki/glpi/GlpiNotifications

sbonn · 2009-10-07 12:46:58

serrait il possible de lier ce post aux évolutions sur les notifications (https://forge.indepnet.net/wiki/glpi/GlpiNotifications)

merci

MoYo · 2009-10-08 22:00:24

c'est fait depuis le 06/03/2009 donc ca ne sert à rien de revenir à la charge tout le temps.

sbonn · 2009-10-09 09:05:31

Désolé

Forum GLPI-Project

Announcement

#1 2009-05-15 14:49:35

Comment configurer les notifications en évitant de se spammer soi-même

#2 2009-06-04 20:55:56

Re: Comment configurer les notifications en évitant de se spammer soi-même

#3 2009-06-05 08:10:35

Re: Comment configurer les notifications en évitant de se spammer soi-même

#4 2009-07-21 11:01:31

Re: Comment configurer les notifications en évitant de se spammer soi-même

#5 2009-07-21 11:11:28

Re: Comment configurer les notifications en évitant de se spammer soi-même

#6 2009-07-21 11:15:41

Re: Comment configurer les notifications en évitant de se spammer soi-même

#7 2009-10-07 12:45:32

Re: Comment configurer les notifications en évitant de se spammer soi-même

#8 2009-10-07 12:46:58

Re: Comment configurer les notifications en évitant de se spammer soi-même

#9 2009-10-08 22:00:24

Re: Comment configurer les notifications en évitant de se spammer soi-même

#10 2009-10-09 09:05:31

Re: Comment configurer les notifications en évitant de se spammer soi-même

Board footer