You are not logged in.
Bonjour,
Nous avons eu un problème similaire avec des courriels qui ne partaient pas, bloquer dans la file d'attente des courriels.
Nous avions un affichage pas logique dans le gestionnaire des actions automatiques pour " Queuedmail"
La date de la prochaine exécution était inférieure "Dès que possible (05-10-2015 12:10)" à la date dernière exécution 05-10-2015 12:15
Le serveur de base de données n'était pas à l'heure, celui-ci n'est pas sur le même serveur que l’application GLPI.
Cordialement.
Offline
Bonjour à tous et merci pur vos réponses.
Vraiment désolé de ne pas avoir pu continuer le suivi, nous avons eu pas mal de soucis chez nos clients sur lesquels nous avons du nous concentrer. Je poste cela au moins par politesse pour les personnes qui essayent de me dépanner et qui ne me voient pas répondre.
Le problème est toujours d'actualité et je n'ai pu encore tester d'autres solutions.
Et là je pars en vacances pour 3 semaines.
Merci à vous donc de ne pas clore ce ticket d'ici là
Bonne journée,
Offline
Merci à vous donc de ne pas clore ce ticket d'ici là
Je ne vois pas pourquoi on fermerait un post qui n'est pas résolu
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 à tous et merci pour vos réponses.
Tout d'abord @Cremos. merci mais notre base GLPI est locale au serveur. Ce dernier est bien à l'heure.
Ensuite @Ladenrée. OK mais c'est bizarre car sur notre vieille version 0.71.2 ça marchait vraiment bien... Ne peut on pas revenir à un fonctionnement similaire ?
Je confirme qu'en exécutant chaque tâche tour par tour, de nouveau c'est au tour de quedmail et ça envoie les messages.
Le truc c'est que pour l'instant il s'agit d'un serveur de test tant que tout ne fonctionne pas correctement donc 0 activité.
OK pour tester en mode CLI mais quel est la différence avec le mode GLPI ? Quand vous dites créer une tâche planifiée, il s'agit simplement d'aller dans le planificateur de tâche (nos serveurs sont sous Wndows) et d'y planifier l’exécution d'un script .bat qui appelle /glpi/front/cron.php régulièrement c'est ça ?
merci d'avance.
Offline
Le mode CLI est exacuté régulièrement suivant la tache panifiée créée contrairement au mode GLPI qui ne s'active qu'avec de l'activité dans le logiciel, donc beacuoup moins régulier.
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,
OK mais vous n'avez pas répondu intégralement à ma question.
Ce que je ne comprends pas bien c'est comment le mode CLI se lance. le paramétrage suffit dans le menu ? (par exemple pour queuedmail : Mode CLI et exécution toutes les 1min). Glpi s'occupe de lancer cela tout seul ?
Ou dois je moi créer un tâche planifier dans windows ? Du genre un script .bat qui contient la ligne de commande :
"C:\Program Files\Internet Explorer\iexplore.exe" http://127.0.0.1:8080/glpi/front/cron.php
Dans ce cas toutes les tâches affectée en mode CLI se lance en même temps ?
J'ai l'impression que cela n'affecte pas que les tâches en mode CLI mais aussi les autres. C'est à dire qu'à chaque fois que j'appelle cron.php (via le script proposé ci dessus), dans le menu "actions automatiques" je vois que "Prochaine action à exécuter", ça passe à la tâche d'après (même ci ces dernières sont en mode GLPI).
Je ne sais pas si je suis bien claire dans ce que j'expose. Mais en même temps le mode d'exécution des tâches n'est pas clair pour moi. Tout ce que je vois, c'est que sur mon serveur de test, lorsque je poste un nouveau ticket le mail par de suite alors que pour le commentaire le mail reste en file d'attente.
Offline
Bonjour,
il vous faut effectivement programmer une tache sur votre serveur pour executer cron.php ( je ne connais pas a syntaxe exacte).
ce script va executer toutes les taches planifiées (mode CLI) qui sont dans les plages et avec la fréquence que vous avez paramétrées :
ça n'empeche pas les taches en mode glpi de s'executer quand vous travaillez sur glpi.
le nombre de tache simultanée se paramètre dans conf générale.
Trouver la panne avant de réparer...
GLPI10.0.16 (ubuntu 22.04 PHP8.1 Mariadb10.6 ) plugins : comportements 2.7.3 reports 1.16.0 formcreator 2.13.9, datainjection 2.13.5 fields 1.21.9
Offline
Bonjour Ladenrée,
merci de ta réponse.
le soucis c'est que ça ne fonctionne pas. J'ai lancé la ligne de commande citée ci dessus. Iexplore s'ouvre et lance bien le cron.php.
Pourtant les mails restent toujours coincés en file d'attente quand je regarde 5min après...
J'ai bien mis queuedmail en mode CLI.
Offline
configuration> actions automatiques>
est ce qu'il y a des actions en attente d'execution ?
configuration> actions automatiques> queuedmail
actif ?
fréquence ?
mode :?
Plage :
maximum d'envoi à chaque fois ?
dernière execution ?
prochaine execution ?
Trouver la panne avant de réparer...
GLPI10.0.16 (ubuntu 22.04 PHP8.1 Mariadb10.6 ) plugins : comportements 2.7.3 reports 1.16.0 formcreator 2.13.9, datainjection 2.13.5 fields 1.21.9
Offline
configuration> actions automatiques>
est ce qu'il y a des actions en attente d'execution ?
=> je ne peux pas voir toutes les tâches en attente d'exécution. Par contre j'ai un triangle jaune avec "Prochaine action à exécuter : Graph"
configuration> actions automatiques> queuedmail
actif ? => oui (statut programmé)
fréquence ? => 1 minute
mode :? => CLI
Plage : => 0 -> 24
maximum d'envoi à chaque fois ? 50 (alors que je n'en ai que 3 en attente)
dernière execution ? 18/11/2015 à 15h11 (lancé manuellement)
prochaine execution ? => dès que possible (8/11/2015 à 15h12)
Offline
Bonjour,
Pour info j'ai essayer de passer à la V0.90 au cas où... Même problème.
Personne ne peut m'aider ? C'est quand même bizarre tout le monde a les mêmes sources je ne devrais pas être le seul à avoir le souci quand même.
Est ce que j'appelle comme il faut cron.php avec la commande suivante ? C'est bien comme ça qu'il faut faire ?
"C:\Program Files\Internet Explorer\iexplore.exe" http://127.0.0.1:8080/glpi/front/cron.php
Merci d'avance.
Offline
bonjour,
en parcourant le forum, j'ai l'impression que les problèmes de cron se posent sur les serveurs Windows.
c'est peut être un hasard ou je n'ai remarqué que ceux là mais il y a peut être une piste .
Trouver la panne avant de réparer...
GLPI10.0.16 (ubuntu 22.04 PHP8.1 Mariadb10.6 ) plugins : comportements 2.7.3 reports 1.16.0 formcreator 2.13.9, datainjection 2.13.5 fields 1.21.9
Offline
Bonjour,
OK merci. Si il y a quelque chose à tester dites moi. je veux bien être votre bêta testeur
Savez vous si une version de GLPI n'est pas atteinte par ce problème sur les serveurs Windows ? Que je mette à jour au moins vers cette version.
merci d'avance,
Offline
bonjour,
avez vous essayé dans votre navigateur d'aller à la page monServeur/glpi/front/cron.php ? et vérifié si ça déclenche des actions ?
après je n'ai pas d'expérience GLPI sur un serveur windows. je ne pourrai pas aider plus.
ATTENTION : j'ai écrit que c'était une piste à explorer, pas que c'était certainement la cause.
Trouver la panne avant de réparer...
GLPI10.0.16 (ubuntu 22.04 PHP8.1 Mariadb10.6 ) plugins : comportements 2.7.3 reports 1.16.0 formcreator 2.13.9, datainjection 2.13.5 fields 1.21.9
Offline
Bonjour,
Quand j'appelle le cron.php manuellement comme vous dites ainsi que par la ligne de commande évoquée juste avant on passe à l'action suivante. Donc je suppose que oui les actions sont déclenchées.
Par contre maintenant que j'ai fait cette manipulation (d'ailleurs à aucun moment je n'ai vu "prochaine action a exécuter ; queued mail") j'ai maintenant :
"Aucune action en attente".
Pourtant les mails sont encore dans la file d'attente !
Y a t'il des tests que vous voulez que je fasse ? Pas de problème pour être le cobaye.
Du coup comment fait on ? Pouvez vous faire remonter l'info aux développeurs ? OK pas de soucis vous n'avez pas l'expérience du GLPI sous Windows mais si le produit a été conçu sur Windows c'est qu'il y a bien quelqu'un qui connait non ? Je vais avoir besoin de mettre cela en place chez un client. Y a t'il un support payant pour GLPI qui puisse me garantir un délai de mise en service ?
En attendant de mon côté je vais essayer de recréer une notification depuis le départ. Je vais aussi essayer d'autres versions plus anciennes pour voir si le souci se reproduit.
Merci d'avance,
Offline
"Aucune action en attente".
juste après l'execution c'est normal, il faut attendre que la minute soit passée pour que queuedmail soit lancée. (il n'y a pas de rafraichissement).
est ce que la tache queuedmail est en action dès que possible ?
Trouver la panne avant de réparer...
GLPI10.0.16 (ubuntu 22.04 PHP8.1 Mariadb10.6 ) plugins : comportements 2.7.3 reports 1.16.0 formcreator 2.13.9, datainjection 2.13.5 fields 1.21.9
Offline
Oui pour en action dès que possible.
Par contre je viens de trouver quelque chose. Vous m'aviez demandé de mettre cette tâche en mode CLI. Depuis que je l'ai repassé en mode GLPI, cette tâche est réapparue en tant que prochaine tâche a exécuter. en lançant cron.php les mails sont partis.
Du coup je laisse quedmail en mode GLPI en paramètre en tâche planifié et je paramètre dans le planificateur de tâches la commande suivante pour l'exécution de manière régulière :
"C:\Program Files\Internet Explorer\iexplore.exe" http://127.0.0.1:8080/glpi/front/cron.php
Ainsi que :
taskkill /F /IM iexplore.exe
Car à chaque fois que le logiciel est exécuté une nouvelle page IE s'ouvre donc on en a rapidement 150...
Du coup il reste un souci. Sur un outil quand même performant qu'est GLPI, utilisable en environnement d'entreprise, je ne comprend pas que cela doit fonctionner avec ce que j'appelle "un morceau de scotch".
N'est il pas possible que les développeurs corrigent cela afin que les tâches soient lancées sans utiliser de script fait à la mano par l'administrateur ?
merci d'avance,
Offline
Bonjour,
Juste pour voir j'ai testé toutes les versions de GLPI.
Le problème semble se produire uniquement à partir de la version 0.85.
Tout passe se bien en 0.48.8.
Par contre j'ai une question. Lors de votre troubleshoot sur la 0.85 et 0.90 vous semblez vous concentrer sur le cron.php et la tâche queued mail. Etes vous bien sûr ?
Si c'était le cas on devrait avoir un problème pour tous les mails envoyés. Or dans l’ordre:
• Quand je crée un ticket le mail part tout de suite
• Quand j’ajoute un suivi , les mails restent en file d’attente
• Quand je clos le ticket (ajout de solution), le mail part tout de suite ! (il ne se met pas en file d’attente par contre les mails du suivi restent bloqués) !
Cela ne vous met pas sur la voie d’un autre souci ? Au niveau de la notification concernant les suivis peut être ?
Merci d’avance
Offline
• Quand je crée un ticket le mail part tout de suite
• Quand j’ajoute un suivi , les mails restent en file d’attente
• Quand je clos le ticket (ajout de solution), le mail part tout de suite ! (il ne se met pas en file d’attente par contre les mails du suivi restent bloqués) !
c'est le fonctionnement normal. (sur ma version en linux, ça fonctionne bien, les suivis partent à chaque execution du cron)
cette file d'attente d'envoi des emails est arrivée en 0.85
Trouver la panne avant de réparer...
GLPI10.0.16 (ubuntu 22.04 PHP8.1 Mariadb10.6 ) plugins : comportements 2.7.3 reports 1.16.0 formcreator 2.13.9, datainjection 2.13.5 fields 1.21.9
Offline
OK mais vous êtes paramétrés comment ? queuedmail est en mode GLPI ou CLI ?
Comment cron.php se lance t'il sur votre serveur ? un tâche planifiée dans le cron de votre système linux ?
Vous me dites que c'est le fonctionnement normal. Donc pour la création de ticket et la cloture de ce dernier, cela ne passe pas par le cron.php ? Y a t'il un paramétrage possible pour que l'envoie de mail au suivi permette que le mail soit envoyé de la même manière que la cloture ?
Offline
queuedmail est en mode CLI
1 ligne dans la crontab du serveur.
je confirme creation et solution sont envoyés directement ( on ne peut pas paramétrer un temps d'envoi) pour les suivis il y a une possibilité d'envoyer avec un décalage suite à des demandes de pouvoir "rattraper un email parti trop vite".
du coup même si on le met à 0, il faut attendre le déclencheur de la cron tab.
(je suis sur un serveur mutualisé et je ne peux pas mettre moins que une heure entre 2 cron ... du coup mes suivis partent toutes les heures, si je suis pressé je force manuellement l'envoi mais je me suis habitué)
Trouver la panne avant de réparer...
GLPI10.0.16 (ubuntu 22.04 PHP8.1 Mariadb10.6 ) plugins : comportements 2.7.3 reports 1.16.0 formcreator 2.13.9, datainjection 2.13.5 fields 1.21.9
Offline
OK. Du coup je vais passer sur la version 0.84.8.
Je ne peux pas mettre les versions 85 et 90 chez mes clients. tout d'abord devoir mettre ce que j'appellerai "un bout de scotch" pour que le logiciel fonctionne normalement n'est pas acceptable ni cohérent. (je parle de l'ajout d'une tâche dans le planificateur de tâche sous windows ou de la crontab sous linux).
En effet c'est un coup à l'oublier. Surtout que cela n'est pas mentionné dans la doc/wiki de GLPI (ou alors j'ai mal vu).
De plus Il n'est pas question de lancer manuellement le queuedmail, les tâches les équipes sur place n'ont pas le temps pour cela. C'est la réalité du terrain. Si nous choisissons un logiciel, c'est parce qu'il nous simplifie la vie. c'est à ça que sert l'informatique.
Ensuite si par exemple il y a un ticket logué en "très urgent" et que les suivis n'arrivent pas avant 1h à chaque fois, ce n'est pas cohérent.
Je ne pense pas être le seul admin qui pense cela.
Pouvez vous transmettre cela aux développeurs ? Le top serait que le logiciel fonctionne de manière autonome et de manières cohérentes sans avoir à rajouter de tâches planifiée.
Si comme vous dites il y a besoin de "rattraper des mails", OK mais que ce soit paramétrable.
En l'état je ne peux pas le proposer aux clients.
Bonne journée
Offline
pour mon cron d'une heure c'est lié à mon serveur hebergé, pas à GLPI.
je ne partage pas votre vision de la tache planifiée comme un bout de scotch.
mais il y a effectivement un problème si les mails de suivi ne partent pas toutes les minutes (qui est un délai acceptable) chez vous. et je vous rejoins sur ce point ce n'est pas normal. (c'est paramétrable mais ça ne marche pas comme prévu chez vous).
Trouver la panne avant de réparer...
GLPI10.0.16 (ubuntu 22.04 PHP8.1 Mariadb10.6 ) plugins : comportements 2.7.3 reports 1.16.0 formcreator 2.13.9, datainjection 2.13.5 fields 1.21.9
Offline
Bonjour,
OK, dans ce cas si ce n'est pas un morceau de scotch (fonctionnement officiel donc), est il possible de l'indiquer dans la doc/wiki, pour qu'on le sache ? (c'est peut être moi qui n'ai pas vu c'est bien possible )
Par contre pouvez vous m'aider SVP pour résoudre le problème pour lequel j'ai au départ ouvert le ticket ? Je perd les catégories de tickets en passant à la V0.83. Ces catégories sont importantes car on sort des rapports régulièrement des soucis rencontrés par catégorie sur le mois et sur l'année. Donc j'aimerai éviter de les recréer car perte d'historique.
Jusqu'à la 0.80, tout se passe bien, mais de la 0.80 à 83 j'ai le message d'erreur suivant en rouge et je le retrouve dans le PHP_log. pour info pas de mysql_log généré.
PHP Notice: Undefined index: tickettasks_id in D:\xampp\htdocs\glpi\install\update_0803_083.php at line 444
PHP Notice: Undefined index: tickettasks_id in D:\xampp\htdocs\glpi\install\update_0803_083.php at line 444
PHP Notice: Undefined index: tickettasks_id in D:\xampp\htdocs\glpi\install\update_0803_083.php at line 444
PHP Notice: Undefined index: tickettasks_id in D:\xampp\htdocs\glpi\install\update_0803_083.php at line 444
PHP Notice: Undefined index: tickettasks_id in D:\xampp\htdocs\glpi\install\update_0803_083.php at line 444
PHP Notice: Undefined index: tickettasks_id in D:\xampp\htdocs\glpi\install\update_0803_083.php at line 444
PHP Notice: Undefined index: tickettasks_id in D:\xampp\htdocs\glpi\install\update_0803_083.php at line 444
Pour info vos collègues Illen et Tsmr ont rencontré ce souci ici mais je ne vois pas de résolution, ils la connaissent peut être :
http://forum.glpi-project.org/viewtopic.php?id=28734
Pour info j'ai essayé de passer version par version et pas tout d'un coup, mais idem. (71.2 à 72.4 puis 78.5 puis 80.7 puis 83.91).
merci d'avance, après je ne vous embête plus
Offline
Pardon je voulais dire le php-errors. Et pas de sql-errors ou mysql-errors.
Voici le contenu intégral de php-errors généré en passant de la 80 à 83 :
Test
2015-12-10 11:45
Notice(8): Undefined index: tickettasks_id
Backtrace :
D:\xampp\htdocs\glpi\inc\toolbox.class.php:490 Toolbox::userErrorHandlerNormal()
D:\xampp\htdocs\glpi\install\update_0803_083.php:444 Toolbox::userErrorHandlerDebug()
D:\xampp\htdocs\glpi\install\update.php:730 update0803to083()
D:\xampp\htdocs\glpi\install\update.php:915 updateDbUpTo031()
2015-12-10 11:45
Notice(8): Undefined index: tickettasks_id
Backtrace :
D:\xampp\htdocs\glpi\inc\toolbox.class.php:490 Toolbox::userErrorHandlerNormal()
D:\xampp\htdocs\glpi\install\update_0803_083.php:444 Toolbox::userErrorHandlerDebug()
D:\xampp\htdocs\glpi\install\update.php:730 update0803to083()
D:\xampp\htdocs\glpi\install\update.php:915 updateDbUpTo031()
2015-12-10 11:45
Notice(8): Undefined index: tickettasks_id
Backtrace :
D:\xampp\htdocs\glpi\inc\toolbox.class.php:490 Toolbox::userErrorHandlerNormal()
D:\xampp\htdocs\glpi\install\update_0803_083.php:444 Toolbox::userErrorHandlerDebug()
D:\xampp\htdocs\glpi\install\update.php:730 update0803to083()
D:\xampp\htdocs\glpi\install\update.php:915 updateDbUpTo031()
2015-12-10 11:45
Notice(8): Undefined index: tickettasks_id
Backtrace :
D:\xampp\htdocs\glpi\inc\toolbox.class.php:490 Toolbox::userErrorHandlerNormal()
D:\xampp\htdocs\glpi\install\update_0803_083.php:444 Toolbox::userErrorHandlerDebug()
D:\xampp\htdocs\glpi\install\update.php:730 update0803to083()
D:\xampp\htdocs\glpi\install\update.php:915 updateDbUpTo031()
2015-12-10 11:45
Notice(8): Undefined index: tickettasks_id
Backtrace :
D:\xampp\htdocs\glpi\inc\toolbox.class.php:490 Toolbox::userErrorHandlerNormal()
D:\xampp\htdocs\glpi\install\update_0803_083.php:444 Toolbox::userErrorHandlerDebug()
D:\xampp\htdocs\glpi\install\update.php:730 update0803to083()
D:\xampp\htdocs\glpi\install\update.php:915 updateDbUpTo031()
2015-12-10 11:45
Notice(8): Undefined index: tickettasks_id
Backtrace :
D:\xampp\htdocs\glpi\inc\toolbox.class.php:490 Toolbox::userErrorHandlerNormal()
D:\xampp\htdocs\glpi\install\update_0803_083.php:444 Toolbox::userErrorHandlerDebug()
D:\xampp\htdocs\glpi\install\update.php:730 update0803to083()
D:\xampp\htdocs\glpi\install\update.php:915 updateDbUpTo031()
2015-12-10 11:45
Notice(8): Undefined index: tickettasks_id
Backtrace :
D:\xampp\htdocs\glpi\inc\toolbox.class.php:490 Toolbox::userErrorHandlerNormal()
D:\xampp\htdocs\glpi\install\update_0803_083.php:444 Toolbox::userErrorHandlerDebug()
D:\xampp\htdocs\glpi\install\update.php:730 update0803to083()
D:\xampp\htdocs\glpi\install\update.php:915 updateDbUpTo031()
Test
10-12-2015 12:14
Notice(8): Undefined index: tickettasks_id
Backtrace :
D:\xampp\htdocs\glpi\inc\toolbox.class.php:490 Toolbox::userErrorHandlerNormal()
D:\xampp\htdocs\glpi\install\update_0803_083.php:444 Toolbox::userErrorHandlerDebug()
D:\xampp\htdocs\glpi\install\update.php:730 update0803to083()
D:\xampp\htdocs\glpi\install\update.php:915 updateDbUpTo031()
10-12-2015 12:14
Notice(8): Undefined index: tickettasks_id
Backtrace :
D:\xampp\htdocs\glpi\inc\toolbox.class.php:490 Toolbox::userErrorHandlerNormal()
D:\xampp\htdocs\glpi\install\update_0803_083.php:444 Toolbox::userErrorHandlerDebug()
D:\xampp\htdocs\glpi\install\update.php:730 update0803to083()
D:\xampp\htdocs\glpi\install\update.php:915 updateDbUpTo031()
10-12-2015 12:14
Notice(8): Undefined index: tickettasks_id
Backtrace :
D:\xampp\htdocs\glpi\inc\toolbox.class.php:490 Toolbox::userErrorHandlerNormal()
D:\xampp\htdocs\glpi\install\update_0803_083.php:444 Toolbox::userErrorHandlerDebug()
D:\xampp\htdocs\glpi\install\update.php:730 update0803to083()
D:\xampp\htdocs\glpi\install\update.php:915 updateDbUpTo031()
10-12-2015 12:14
Notice(8): Undefined index: tickettasks_id
Backtrace :
D:\xampp\htdocs\glpi\inc\toolbox.class.php:490 Toolbox::userErrorHandlerNormal()
D:\xampp\htdocs\glpi\install\update_0803_083.php:444 Toolbox::userErrorHandlerDebug()
D:\xampp\htdocs\glpi\install\update.php:730 update0803to083()
D:\xampp\htdocs\glpi\install\update.php:915 updateDbUpTo031()
10-12-2015 12:14
Notice(8): Undefined index: tickettasks_id
Backtrace :
D:\xampp\htdocs\glpi\inc\toolbox.class.php:490 Toolbox::userErrorHandlerNormal()
D:\xampp\htdocs\glpi\install\update_0803_083.php:444 Toolbox::userErrorHandlerDebug()
D:\xampp\htdocs\glpi\install\update.php:730 update0803to083()
D:\xampp\htdocs\glpi\install\update.php:915 updateDbUpTo031()
10-12-2015 12:14
Notice(8): Undefined index: tickettasks_id
Backtrace :
D:\xampp\htdocs\glpi\inc\toolbox.class.php:490 Toolbox::userErrorHandlerNormal()
D:\xampp\htdocs\glpi\install\update_0803_083.php:444 Toolbox::userErrorHandlerDebug()
D:\xampp\htdocs\glpi\install\update.php:730 update0803to083()
D:\xampp\htdocs\glpi\install\update.php:915 updateDbUpTo031()
10-12-2015 12:14
Notice(8): Undefined index: tickettasks_id
Backtrace :
D:\xampp\htdocs\glpi\inc\toolbox.class.php:490 Toolbox::userErrorHandlerNormal()
D:\xampp\htdocs\glpi\install\update_0803_083.php:444 Toolbox::userErrorHandlerDebug()
D:\xampp\htdocs\glpi\install\update.php:730 update0803to083()
D:\xampp\htdocs\glpi\install\update.php:915 updateDbUpTo031()
Test
2015-12-10 12:17
Notice(8): Undefined index: tickettasks_id
Backtrace :
D:\xampp\htdocs\glpi\inc\toolbox.class.php:490 Toolbox::userErrorHandlerNormal()
D:\xampp\htdocs\glpi\install\update_0803_083.php:444 Toolbox::userErrorHandlerDebug()
D:\xampp\htdocs\glpi\install\update.php:730 update0803to083()
D:\xampp\htdocs\glpi\install\update.php:915 updateDbUpTo031()
2015-12-10 12:17
Notice(8): Undefined index: tickettasks_id
Backtrace :
D:\xampp\htdocs\glpi\inc\toolbox.class.php:490 Toolbox::userErrorHandlerNormal()
D:\xampp\htdocs\glpi\install\update_0803_083.php:444 Toolbox::userErrorHandlerDebug()
D:\xampp\htdocs\glpi\install\update.php:730 update0803to083()
D:\xampp\htdocs\glpi\install\update.php:915 updateDbUpTo031()
2015-12-10 12:17
Notice(8): Undefined index: tickettasks_id
Backtrace :
D:\xampp\htdocs\glpi\inc\toolbox.class.php:490 Toolbox::userErrorHandlerNormal()
D:\xampp\htdocs\glpi\install\update_0803_083.php:444 Toolbox::userErrorHandlerDebug()
D:\xampp\htdocs\glpi\install\update.php:730 update0803to083()
D:\xampp\htdocs\glpi\install\update.php:915 updateDbUpTo031()
2015-12-10 12:17
Notice(8): Undefined index: tickettasks_id
Backtrace :
D:\xampp\htdocs\glpi\inc\toolbox.class.php:490 Toolbox::userErrorHandlerNormal()
D:\xampp\htdocs\glpi\install\update_0803_083.php:444 Toolbox::userErrorHandlerDebug()
D:\xampp\htdocs\glpi\install\update.php:730 update0803to083()
D:\xampp\htdocs\glpi\install\update.php:915 updateDbUpTo031()
2015-12-10 12:17
Notice(8): Undefined index: tickettasks_id
Backtrace :
D:\xampp\htdocs\glpi\inc\toolbox.class.php:490 Toolbox::userErrorHandlerNormal()
D:\xampp\htdocs\glpi\install\update_0803_083.php:444 Toolbox::userErrorHandlerDebug()
D:\xampp\htdocs\glpi\install\update.php:730 update0803to083()
D:\xampp\htdocs\glpi\install\update.php:915 updateDbUpTo031()
2015-12-10 12:17
Notice(8): Undefined index: tickettasks_id
Backtrace :
D:\xampp\htdocs\glpi\inc\toolbox.class.php:490 Toolbox::userErrorHandlerNormal()
D:\xampp\htdocs\glpi\install\update_0803_083.php:444 Toolbox::userErrorHandlerDebug()
D:\xampp\htdocs\glpi\install\update.php:730 update0803to083()
D:\xampp\htdocs\glpi\install\update.php:915 updateDbUpTo031()
2015-12-10 12:17
Notice(8): Undefined index: tickettasks_id
Backtrace :
D:\xampp\htdocs\glpi\inc\toolbox.class.php:490 Toolbox::userErrorHandlerNormal()
D:\xampp\htdocs\glpi\install\update_0803_083.php:444 Toolbox::userErrorHandlerDebug()
D:\xampp\htdocs\glpi\install\update.php:730 update0803to083()
D:\xampp\htdocs\glpi\install\update.php:915 updateDbUpTo031()
Merci d'avance
Offline