Veuillez m'excuser pour la réponse très tardive..
Le problème venait de l'action automatique "alertnotclosed" qui, générant un rapport contenant les tickets qui n'avaient pas été modifiés depuis un certain temps, envoyait un mail à chaque utilisateur présent dans les groupes attribués aux tickets présents dans ces rapports.
Le problème a donc été résolu une fois ces tickets triés.
Je vous remercie sincèrement pour votre aide, grâce à vous notre parc de tickets est désormais à jour.
Passez une excellente journée.
]]>Si vous désactivez la configuration des notifications et la tache automatique Queuednotification, aucune notification ne partira.
Ensuite vérifier chaque notification de paramétrée.
Lors d'une migration de notre serveur GLPI de la version 0.83.91 à la version 9.4.0, nous avons rencontré un problème assez conséquent. Après la migration de la base de données et l'activation des collecteurs mis en place, GLPI s'est mis à envoyer un mail à chaque personne présente sur le parc pour chaque ticket créé, suivi créé, tâches créées. Sachant que notre GLPI contient plus de 25000 tickets dans notre base de connaissances, cela a généré de lourds ralentissements sur le serveur et une insatisfaction utilisateur.
Plusieurs problèmes ont suivi :
1- La saturation des journaux de notifications avec plus de 4 millions de journaux, ce qui ralentissait énormément GLPI et bloquait les actions suivantes.
2- L'envoi massif de mails à nos utilisateurs (ce que nous souhaitons éviter à tout prix)
Configuration précédente :
Debian 6.0.3
GLPI 0.83.91
Apache 2.2.16
Php 5.3.3
MySql 14.14
Configuration nouvelle :
Debian 9.8
GLPI 9.4.0
Apache 2.4.25
Php 7.0.33
MySQL (MariaDB) 15.1
Nous prévoyons une nouvelle mise en production mais ce problème doit être réglé avant, pouvez-vous me venir en aide ?
Merci beaucoup.
]]>