You are not logged in.
Bonjour,
Je souhaite envoyer un mail de notification à un prestataire externe lors qu'un mail est affecté à son groupe.
J'ai essayer avec la notification "Update Ticket" mais cela envoi également une notification lors de changements sur l'incident (ce que je ne souhaite pas.)
Je me suis donc tourné vers la création automatique de la tache pour envoyer un mail avec la notification "Add Task" mais je me retrouve confronté au problème suivant :
La création de la tache se fait avant l'ajout du nouveau groupe. Par conséquent lors de l'envoi de la notification de la tache, le ticket n'est pas encore attribué au groupe.
Est-il possible de modifier l'ordre de ces deux actions automatique (même si je doit pour cela les déplacer dans le code source) ?
Merci d'avance de votre réponse.
Last edited by Balthor7 (2014-06-05 12:56:50)
Mon environnement Glpi :
GLPI V0.84.4
Plugin : Escalades V2.0.1 et Rapports V1.7.0
Offline
Le groupe n'est pas ajouté à une tache mais au ticket.
L'évènement lié à l'ajout d'un groupe est bien le "Update ticket".
Pour faire ce que vous souhaitez, il faut faire un plugin pour surcharger le comportement du coeur
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
Bonjour yllen,
Merci pour ta réponse.
J'ai constaté entre temps que la tache qui est créé lors de l'affectation à un groupe de technicien n'est pas native à GLPI mais viens du plugin "Escalade".
Il faut donc que je regarde du coté du plugin si il est possible de modifier l'ordre des actions (entre la création de la tache et l'affectation au groupe.)
Je suis désolé de mon erreur mais c'est pas toujours simple de devoir repasser sur une version de GLPI quand on n'a pas participé à la mise en place de l’outil. (Je découvre encore des paramètres tous les jours...)
Je vais donc chercher du coté de du plugin "Escalade" mais si tu à une idée sur le sujet je suis preneur.
----------------------
EDIT :
La fonction d'ajout à l'historique s'appelle "addHistoryOnAddGroup" déclaré à la ligne 175 du fichier "ticket.class.php" du plugin Escalade V2.0.1
L'appel de la fonction est réalisé dans le fichier hook.php à la ligne 229.
function plugin_escalade_pre_item_add_group_ticket($item) {
if ($item instanceof Group_Ticket) return PluginEscaladeTicket::addHistoryOnAddGroup($item);
return $item;
}
Il semble que l'ajout du groupe au ticket soit effectué dans le fichier hook.php à la ligne 234.
function plugin_escalade_item_add_group_ticket($item) {
if ($item instanceof Group_Ticket) {
return PluginEscaladeTicket::processAfterAddGroup($item);
}
return $item;
}
Si je ne me trompe pas il me suffirais d'inversé l'ordre de ces deux fonctions pour que la tache soit créé après l'ajout du groupe.
Je ne possède pas d'environnement de test alors, je voudrais avoir votre avis avant d'effectuer le changement...
Last edited by Balthor7 (2014-06-06 13:03:50)
Mon environnement Glpi :
GLPI V0.84.4
Plugin : Escalades V2.0.1 et Rapports V1.7.0
Offline
Je ne connait pas ce plugin, mais dans le coeur, le pre_item_add est exécuté avant le item_add.
Donc inverser le contenu des 2 fonctions pourrait peut être suffire.
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
Pour faire cela de façon plus "propre", il ne serait pas mieux d'utiliser la fonction (si elle existe)"post_item_add" à la place de "pre_item_add" ?
Mon environnement Glpi :
GLPI V0.84.4
Plugin : Escalades V2.0.1 et Rapports V1.7.0
Offline
le pre_item_add modifie le contenu du $input en tout début (avant les traitements du coeur et l'enregistrement dans la base).
Le post-additem intervient une fois que le add a été entièrement fait, c'est à dire après enregistrement dans la base.
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
Bonjour,
Je m'excuse de répondre si tard sur le ticket mais il est compliqué d'effectuer ces changements sans environnement de test.
Je viens donc enfin de pouvoir effectuer le test.
La conclusion est : il n'y a plus la création de la tache qui est effectuée dans lors de l'attribution à un groupe.
Voici le code utilisé après modification :
function plugin_escalade_pre_item_add_group_ticket($item) {
if ($item instanceof Group_Ticket) {
return PluginEscaladeTicket::processAfterAddGroup($item);
}
return $item;
}
function plugin_escalade_item_add_group_ticket($item) {
if ($item instanceof Group_Ticket) return PluginEscaladeTicket::addHistoryOnAddGroup($item);
return $item;
}
Voici l'ancien code :
function plugin_escalade_pre_item_add_group_ticket($item) {
if ($item instanceof Group_Ticket) return PluginEscaladeTicket::addHistoryOnAddGroup($item);
return $item;
}
function plugin_escalade_item_add_group_ticket($item) {
if ($item instanceof Group_Ticket) {
return PluginEscaladeTicket::processAfterAddGroup($item);
}
return $item;
}
Il ne me semble pas avoir fait d'erreurs en inversant les 2 fonctions...
Je ne comprend pas pourquoi l'ajout de la tâche n'est plus effectué.
Avez-vous une idée ?
je vais voir de mon coté si je trouve autre chose.
Mon environnement Glpi :
GLPI V0.84.4
Plugin : Escalades V2.0.1 et Rapports V1.7.0
Offline