You are not logged in.
Pages: 1
Voici le problème :
Comme j'ai des notifications non envoyées, j'ai tout désactivé et fabriqué ma propre notification et le gabarit qui lui est associé. J'ai mis comme destinataire : demandeur, observateur et technicien chargé du ticket. En évènement, j'ai mis "Nouveau ticket". Si je crée un nouveau ticket avec l'interface simplifiée sans observateur, la notification est envoyée au demandeur (jusque là, tout est ok). Si je précise un observateur, aucune notification n'est envoyée. Si je modifie la description du ticket, la notification est alors envoyée au demandeur et à l'observateur. Il y donc quelque chose qui foire dans l'envoi des notifications...
Merci de me dire si vous arrivez à reproduire le pb.
Pour info
GLPI 9.4.3 ( => /var/www/glpi)
Installation mode: TARBALL
Operating system: Linux UCD-043 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u5 (2019-08-11) x86_64
PHP 7.0.33-0+deb9u3 apache2handler (Core, PDO, Phar, Reflection, SPL, SimpleXML, Zend OPcache, apache2handler, apc, apcu, bz2,
calendar, ctype, curl, date, dom, exif, fileinfo, filter, ftp, gd, gettext, hash, iconv, imap, json, ldap, libxml, mbstring,
mysqli, mysqlnd, openssl, pcre, pdo_mysql, posix, readline, session, shmop, snmp, sockets, standard, sysvmsg, sysvsem, sysvshm,
tokenizer, wddx, xml, xmlreader, xmlrpc, xmlwriter, xsl, zip, zlib)
Setup: max_execution_time="30" memory_limit="128M" post_max_size="8M" safe_mode="" session.save_handler="files"
upload_max_filesize="6M"
Software: Apache/2.4.25 (Debian) (Apache/2.4.25 (Debian) Server at testglpi.seinegrandslacs.fr Port 80)
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0
Server Software: Debian 9.8
Server Version: 10.1.38-MariaDB-0+deb9u1
Server SQL Mode:
Parameters: root@localhost/glpi
Host info: Localhost via UNIX socket
Offline
vos notification sont elles dans la file d'attente : ( administration>file d'attente des notifications) ?
Trouver la panne avant de réparer...
GLPI10.0.10 (ubuntu 22.04 PHP8.1 Mariadb10.6 ) plugins : comportements 2.7.2 reports 1.16.0 formcreator 2.13.8, datainjection 2.13.4 fields 1.21.6
Offline
Non, je viens de vérifier.
Offline
Pour info, j'ai refait les tests en mettant "queuednotification" en mode CLI au lieu de GLPI et en désactivant tous les plugins : même comportement
Offline
Bonjour,
En fait, j'avais tellement de ligne dans la file d'attent des notifications que je ne les voyais pas toute. J'ai donc fait les actions suivantes :
-Suppression de toutes les lignes de la file d'attente des notifications
-Réduction de la taille du fichier php-errors.log (3,1 Go à 75 Ko)
-Réduction de la taille du fichier sql-errors.log (350 Mo à 758 Ko)
Moyennant quoi, tout fonctionne correctement ! (c'est suppression des lignes de notification qui a réglé le pb.
Donc milles excuses puisque le bug, c'était moi ..!
Offline
vos notification sont elles dans la file d'attente : ( administration>file d'attente des notifications) ?
Bonjour,
Lorsqu'une action qui mène à une notifications est faite, je la vois apparaître dans "administration -> file d'attente des notifications".
Je reçois la notifications seulement après plusieurs heures voir plusieurs jours...
Lorsque je fais un test "envoyer un courrier de test à l'administrateur" dans notifications, je reçois bien le courrier de test instantanément.
Avez vous déjà eu ce problème ?
Merci
Offline
je n'ai pas ce problème, mais je vois une cause très probable :
si l'action "queuednotification" est en mode CLI au lieu de GLPI : il faut ajouter un cron sur le serveur qui lance (toutes les 5 minutes par exemple) glpi/front/cron.php : et là au maximum après 5 minutes la notification est envoyée (sauf si vous mettez une fréquence supérieure dans le paramétrage de queudnotification )
si l'action "queuednotification" est en mode GLPI : c'est les creations de tickets etc.. dans glpi qui déclenchent les envois. si vous n'avez pas assez d'activité, la nuit le week end et pendant la pause café, glpi n'envoie pas.
je préconise le mode cli avec un cron ( linux) ou une tache planifiée (windows).
attention au nombre d'executions simultanées dasn config generale ( 1 peut être trop peu)
Trouver la panne avant de réparer...
GLPI10.0.10 (ubuntu 22.04 PHP8.1 Mariadb10.6 ) plugins : comportements 2.7.2 reports 1.16.0 formcreator 2.13.8, datainjection 2.13.4 fields 1.21.6
Offline
Nous avons aussi eu des problèmes sur les envois et autres comportements inhabituels à cause d'un problème ... d'heure qui n'était plus à la bonne heure. Cela perturbait le pare-feu car la différence était trop importante
Manger un castor, c'est sauver un arbre.
Quand on est mort, on ne sait pas qu'on est mort ; c'est pour les autres que c'est difficile. Quand on est con, c'est pareil !
Offline
L'heure est bien synchro
si l'action "queuednotification" est en mode GLPI : c'est les creations de tickets etc.. dans glpi qui déclenchent les envois. si vous n'avez pas assez d'activité, la nuit le week end et pendant la pause café, glpi n'envoie pas.
l'action "queuednotification" est en mode GLPI. Donc si je comprends bien, si par exemple un contrat arrive à terme (considérons que les notifs soient programmé pour les contrats) je ne reçois pas de notifications jusqu'à la création d'un tickets qui va débloquer toutes les autres notifications en attente ?
Last edited by albertoo (2019-08-30 15:16:58)
Offline
c'est le principe.(il n'y a pas que la creation de ticket qui déclenche, mais en gros c'est ça)
l'avantage du cron c'est que ça simule l'activité, et donc ça marche 24h/24 7j/7
attention : il faut planifier l'action automatique contrats pour generer les notifications de fin de contrat en file d'attente ET planifier queuedmail pour envoyer les notifications
Trouver la panne avant de réparer...
GLPI10.0.10 (ubuntu 22.04 PHP8.1 Mariadb10.6 ) plugins : comportements 2.7.2 reports 1.16.0 formcreator 2.13.8, datainjection 2.13.4 fields 1.21.6
Offline
Pages: 1