You are not logged in.
Bonjour à tous et merci beaucoup pour tout le travail et le professionnalisme dont vous faites preuves pour le développement d'une application libre de droit. Vous êtes de véritables pionniers d'internet et je vous souhaite de réussir tout ce que vous entreprendrez!
Je poste aujourd'hui cette discussion sans savoir si mon problème relève d'une mauvaise utilisation de GLPI ou bien d'un bogue. En tout cas je n'ai pas trouvé de discussion ni de bug concernant ce point sur le forum donc je pencherai plus pour une mauvaise utilisation. Voici mon infrastructure technique :
-GLPI 9.3.2
-Extensions manquantes :Apcu, ZendOpCache
-Infrastructure générale : PHP-5.6.38, IMAP 5.0.3, OPENLDAP-2.1.30, openssl-1.0.2n, autres extensions demandées par GLPI
-OS : CentOs 7
Je cherche à réaliser le workflow suivant :
-Lorsqu'un incident est ouvert un temps de résolution TR lui est définit grâce à un SLA à +30 minutes pour l'exemple. 20 minutes avant le TR, le champ "catégorie" doit être mis-à-jour. 10 minutes avant le TR, le champs catégorie doit à nouveau être mis-à-jour.
Pour ce faire "SLA1" est créé dans le nouveau niveau de service GLPI-PROJECT ainsi qu'une règle métier pour l'attribuer à l'ouverture d'un ticket si ce dernier est un incident. Cela fonctionne : Le ticket dispose bien d'un Temps de résolution et en passant la souris sur l'information de "SLA1" j'obtiens le message "Prochaine escalade" avec le bon délais.
J'ai également programmé l'action automatique slaticket en mode CLI avec un script CRON (qui lance toutes les actions automatiques) pour une exécution toutes les 5 minutes. Le calendrier utilisé est 24h/24 7j/7. La plupart des actions automatiques sont d’ailleurs programmées en mode GLPI, je ne sais pas si cela peut avoir un impact (phase de pré-production très peu utilisée).
La première escalade s'enclenche comme prévu à -20 minute du TR mais c'est là que je me retrouve bloqué :
L'escalade de mon SLA s'arrête : en passant la souris sur l'information de "SLA1", le fenêtre m'indiquant la date de prochaine escalade est désormais vierge. Quand j'arrive à -10 minutes du TR, j'ai beau relancer manuellement l'action automatique slaticket, ma règle métier, rien n'y fait, le ticket n'escalade toujours pas.
Pour voir la configuration de mes niveaux d'escalade plus en détail :
- Les deux niveaux ont pour critère "Statut est Nouveau". Ce n'est pas ce qui est indiqué dans la documentation mais cela marche pour la première escalade. J'ai également essayé avec "Statut n'est pas Nouveau" mais dans ce cas même le niveau 1 d'escalade ne se lance pas.
- Les deux niveaux ont pour action "Rappels automatiques pour les SLAs Envoyer Oui" (La notification a été paramétrée et fonctionne).
- La première escalade a une action spécifique "Catégorie Assigner Escalade Routage > Lvl1" pour l'exemple. L'exécution est fixée à -20 minutes et le niveau est actif.
- La seconde escalade a une action spécifique "Catégorie Assigner Escalade Routage > Lvl2" pour l'exemple. L'exécution est fixée à -10 minutes et le niveau est actif.
Aujourd'hui et ce malgré tous les tests effectués, aucun ticket n'a dépassé la catégorie "Escalade Routage > Lvl1". La méthode fonctionnelle mise-en-place sur mon installation est la création d'un SLA "SLA2" dont le temps de résolution est fixé à +10 minutes. A la première escalade de SLA1, je rajoute l'action "Attribuer le SLA SLA2" et je rentre les actions de la seconde escalade en tant qu'actions à effectuer lors de la première escalade de SLA2 (escalade au temps de résolution). Cette méthode fonctionne pour les métiers mais n'est pas logique ni contractuelle. Au mieux il faudrait 1 SLA propre à chaque fournisseur de prestations informatique pour une organisation plus compréhensible.
J'espère avoir été aussi clair que possible. Pourriez-vous m'aider je vous prie? Est-ce que quelqu'un comprend pourquoi mes SLA ne disposent que d'un niveau d'escalade fonctionnel? Toute aide ou procédure alternative que vous pourrez me proposer est la bienvenue.
Respectueusement,
T. Imhotep
Offline
J'ai reproduit ce problème avec la version 9.3.3.
Soit c'est un bug, soit je fais la même erreur que T-imotep !
Offline
Je confirme votre bug : https://github.com/glpi-project/glpi/issues/5319
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,
Le patch suivant corrige le problème: https://github.com/glpi-project/glpi/pull/5805
A noter que ça ne corrige que les cas où le premier niveau d'escalade n'a pas encore été enclenché.
Offline