You are not logged in.
Pages: 1
Topic closed
Bonsoir,
Toujours dans le cadre de mon modèle de notifications complexe sous GLPI 0.78.2, j'ai testé le collecteur de suivis permettant d'injecter des suivis aux tickets par email.
Tout fonctionne pratiquement parfaitement, excepté l'appel de la balise ##FOREACH LAST followups##.
En effet, il semble que le collecteur récupère tous les emails de la boite configurée, les injecte et envoie seulement les notifications par après. Le contenu du dernier suivi est donc toujours le premier (ou dernier?) suivi récupéré par le collecteur (même si il y en a plusieurs).
Voici un exemple concret :
1) un utilisateur envoie un suivi "test1" par email
2) un utilisateur envoie un suivi "test2" par email
3) le collecteur récupère les 2 emails et les injecte dans les suivis du ticket
4) je reçois un premier email dont le contenu de ##FOREACH LAST followups## est "test1"
5) je reçois un deuxième email dont le contenu de ##FOREACH LAST followups## est également "test1"
C'est très perturbant pour l'utilisateur de recevoir deux emails contenant le même suivi et de rater un suivi par la même occasion.
Est-il envisageable de modifier ce comportement ou vaut-il mieux ne pas utiliser la balise ##FOREACH LAST followups## avec le suivi par email?
Nicolas
GLPI 0.78.2 on Debian Etch 64 bits running on Xen 4.0
Offline
les notifications sont envoyées à chaque action (donc chaque ajout de suivi).
je ne comprend donc pas le soucis.
MoYo - Julien Dombre - Association INDEPNET
Contribute to GLPI : Support Contribute References Freshmeat
Offline
Bonjour,
Je pensais aussi que les notifications étaient envoyées à chaque action, mais ça ne semble pas être le cas avec le collecteur (ou alors j'ai un autre problème de cache, de base de données, ou je ne sais pas quoi).
Le souci est que la balise
##FOREACH LAST followups##
Le ##followup.date##, ##followup.author## a écrit:
##followup.description##
##ENDFOREACHfollowups##
utilisée avec le suivi pas email me renvoie systématiquement le dernier suivi encodé des X emails collectés.
Le problème n'apparaît que si le collecteur relève plusieurs mails d'un coup. Dans ce cas, ##followup.description## contient la même chose pour tous les tickets relevés (j'ai déjà vu le phénomène avec 3 emails relevés en une seule fois) . J'oublie de préciser que je fais mes tests en relevant les mails manuellement via le bouton "Récupérer maintenant", peut-être que ça a un impact.
Si personne d'autre n'a ce genre de problème, je vais essayer de trouver ce qu'il se passe en ajoutant du debug dans le collecteur.
Nicolas
GLPI 0.78.2 on Debian Etch 64 bits running on Xen 4.0
Offline
Après des heures de debug, j'ai finalement trouvé d'où venait le problème : le collecteur relève les emails et ajoute des suivis avec des dates identiques (à la seconde près). La fonction getDatasForTemplate récupère ensuite ces suivis et les reclasse par date (et dans les mauvais ordre puisque les dates sont identiques).
Voici un patch qui corrige le problème (en reclassant par id) :
--- inc/notificationtargetticket.class.php.orig 2011-02-02 17:42:22.000000000 +0100
+++ inc/notificationtargetticket.class.php 2011-02-02 17:33:39.000000000 +0100
@@ -732,7 +732,7 @@
if (!isset($options['additionnaloption']) || !$options['additionnaloption']) {
$restrict .= " AND `is_private` = '0'";
}
- $restrict .= " ORDER BY `date` DESC";
+ $restrict .= " ORDER BY `id` DESC";
//Task infos
$tasks = getAllDatasFromTable('glpi_tickettasks',$restrict);
Je ne sais pas du tout quelle influence peut avoir ce patch sur le fonctionnement de GLPI, mais pour l'instant, il résoud mon problème.
Nicolas
GLPI 0.78.2 on Debian Etch 64 bits running on Xen 4.0
Offline
j'ai plutot écrit pour être sur
ORDER BY `date` DESC, `id` ASC
MoYo - Julien Dombre - Association INDEPNET
Contribute to GLPI : Support Contribute References Freshmeat
Offline
ticket suivant : https://forge.indepnet.net/issues/2627
merci du retour et du debug.
MoYo - Julien Dombre - Association INDEPNET
Contribute to GLPI : Support Contribute References Freshmeat
Offline
Pages: 1
Topic closed