search

pluginsGLPI / formcreator

GLPI Plugin Formcreator (DOWNLOAD : https://github.com/pluginsGLPI/formcreator/releases)
http://www.teclib-edition.com
GNU General Public License v3.0
174 stars 125 forks source link

Date d'ouverture ne remonte pas dans les tickets #2127

Closed amongreville closed 3 years ago

amongreville commented 3 years ago

Describe the bug A clear and concise description of what the bug is.

To Reproduce Steps to reproduce the behavior:

  1. Créer un formulaire
  2. Ajouter une cible vers ticket

Expected behavior Aucune Date ne remonte lors de la création du ticket

Screenshots If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

btry commented 3 years ago

Bonjour

Quelle version de Formcreator ?

Pouvez vous aussi montrer un exemple de date saisie ?

amongreville commented 3 years ago

Bonjour, La version de GLPI est 9.5.3 et la version de Formcreator est la 2.11.1.

Voici les captures

Capture3 Capture Capture2

Merci d'avance,

amongreville commented 3 years ago

Bonjour,

Même en insérant un champ "date" ou "date&heure", j'obtiens la même anomalie.

btry commented 3 years ago

Bonjour

Alors.. que dire ?

J'ai reproduit, commencé à chercher, puis le bug a disparu spontanément. Je n'arrive plus à reproduire.

J'ai fait un correctif pour un plantage si on ne remplit pas le champ date : 940bfee2ecf7a22a4fc5033d81c90536e0baeac8. L'annuler ne me permet pas de reproduire de nouveau.

btry commented 3 years ago

Le message d'erreur semble provenir de GLPI, quand on ajoute ou modifie quelque chose. Impossible de savoir quoi sans backtrace.

Comme je ne reproduis plus, j'ai besoin que l'un d'entre vous applique ce patch (de préférence sur une instance de TESTS) pour récupérer un backtrace. A priori c'est à l'endroit décrit dans le diff que le message est émis.

diff --git a/inc/commondbtm.class.php b/inc/commondbtm.class.php
index f4526ee058..dec57b4c81 100644
--- a/inc/commondbtm.class.php
+++ b/inc/commondbtm.class.php
@@ -4069,6 +4069,7 @@ class CommonDBTM extends CommonGLPI {
                      preg_match($pattern, $value, $regs);
                      if (empty($regs)) {
                         $unset = true;
+                        Toolbox::logDebug("formcreator: date error message debug", Toolbox::backtrace(''));
                      }
                      break;

Le backtrace sera enregistré dans php-errors.log.

Je suis en attente de retour pour avancer sur ce bug.

amongreville commented 3 years ago

D'accord, j'active une instance de tests

La version PHP n'a pas d'incidence ?

btry commented 3 years ago

Du moment que vous respectez les prérequis de GLPI, pas de souci. PHP 7.2 minimum.

btry commented 3 years ago

Bonjour

Avez vous pu générer le backtrace à l'aide du patch ?

amongreville commented 3 years ago

Bonjour,

Malgré l'ajout de la ligne dans commondbtm.class.php de case 'datetime' : // Date is already "reformat" according to getDateFormat() $pattern = "/^([0-9]{4})-([0-9]{1,2})-([0-9]{1,2})"; $pattern .= "([_][01][0-9]|2[0-3]:[0-5][0-9]:[0-5]?[0-9])?/"; pregmatch($pattern, $value, $regs); if (empty($regs)) { $unset = true; Toolbox::logDebug("formcreator: date error message debug", Toolbox::backtrace(''));_ } break;

J'ai aucune ligne concernant le libellé qui remonte dans php-errors.log

amongreville commented 3 years ago

j'ai par-contre cette erreur dans sql-errors.log :

[2021-02-24 11:34:10] glpisqllog.ERROR: DBmysql::query() in D:\WAMP\PROD\HTTPD\WWW\ sql-errors.log glpi\inc\dbmysql.class.php line 306 *** MySQL query error: SQL: INSERT INTO glpi_plugin_formcreator_issues (original_id, sub_itemtype, name, status, date_creation, date_mod, entities_id, is_recursive, requester_id, users_id_validator, groups_id_validator, comment, display_id) VALUES ('2021022427', 'Ticket', 'demande en ligne HS', '2', NULL, '2021-02-24 11:34:09', '6', '0', '34', '', '', '<div><h1>Données du formulaire</h1><h2>Informations sur la demande : </h2><div><b>1) Type de demande : : </b>DSI > 05 - Cellule Hotline</div><div><b>2) Urgence : : </b>Moyenne</div><div><b>3) Lieu : : </b>00 - SITES COMMUNS > 01 - VICHY COMMUNAUTE > 01 - HOTEL D\'AGGLOMERATION > ETAGE 0 RDC > 000 > GUICHET 003</div><div><b>4) Demande pour un autre agent : : </b>NON</div><h2>Votre demande : </h2><div><b>5) Libellé de la demande : : </b>demande en ligne HS</div><div><b>6) Description de la demande : : </b><p>à faire</p></div><h2>Pièces jointes : </h2><div><b>7) Documents : : </b>Pas de document rattaché</div></div>', 't_2021022427') Error: Column 'date_creation' cannot be null Backtrace : inc\dbmysql.class.php:1127
inc\commondbtm.class.php:602 DBmysql->insert() inc\commondbtm.class.php:1142 CommonDBTM->addToDB() plugins\formcreator\inc\formanswer.class.php:1289 CommonDBTM->add() plugins\formcreator\inc\formanswer.class.php:1013 PluginFormcreatorFormAnswer->createIssue() inc\commondbtm.class.php:1143 PluginFormcreatorFormAnswer->post_addItem() plugins\formcreator\front\form.form.php:142 CommonDBTM->add() {"user":"34@CAWEB","mem_usage":"0.052\", 33.58Mio)"}

btry commented 3 years ago

Bonjour

Je vais faire un patch pour le souci de valeur null non permise.

Si on ne génère pas de backtrace. Est ce que l'erreur se produit encore ? Ou a t elle disparu comme je l'ai observé ?

amongreville commented 3 years ago

L'anomalie persiste malgré la suppression du backtrace j'ai pris le contenu du support 2.11.0, est-ce la bonne méthode ? Capture-support

Que pensez-vous de pouvoir associer la date à une question via le paramétrage de la cible ? Comme pour les champs catégories, lieux, ... Capture-date

Sauf si une autre option le permet. Que pensez-vous également, d'avoir l'option "Maintenant" dans le pré-rempilage d'une zone date ? Capture-saisie

Encore merci pour votre aide,

btry commented 3 years ago

Bonjour

Ne mélangeons pas tout dans le même ticket. Il faut rester ici sur le souci lié au message d'erreur. Pour les demandes de fonctionnalité, contactez nous : contact@teclib.com .

Pour appliquer le patch vous devez récupérer le "diff" et l'appliquer avec la commande patch. Si vous avez juste pris la branche support/2.11.0, le patch n'est pas inclus, surtout qu'il s'agit d'une modification visant à faire du debug.

amongreville commented 3 years ago

Merci pour l'information, Je dois bien lancer cette commande : diff -u D:\WAMP\PROD\HTTPD\WWW\glpi\plugins\formcreator C:\TEMP\new\formcreator-develop > prog.patch puis : patch -p0 < prog.patch

amongreville commented 3 years ago

Je viens d'essayer la version 2.11.2 : l'anomalie persiste.

Capture-2-11-2

btry commented 3 years ago

Non. Copiez / collez le diff que j'ai partagé dans un fichier à la racine de Formcreator. Disons debug.patch

Ensuite toujours dans le même dossier faites patch -p1 < debug.patch

La version 2.11.2 que je suis en train de préparer ne contient pas de fix pour ce problème, puisqu'il n'est pas encore résolu.

amongreville commented 3 years ago

Bonjour,

Je n'ai pas retrouvé de fichier *.patch dans les branches et 940bfee2ec

btry commented 3 years ago

Il faut juste copier dans un fichier le patch de ce commentaire : https://github.com/pluginsGLPI/formcreator/issues/2127#issuecomment-779851341

amongreville commented 3 years ago

La correction est appliquée mais l'erreur persiste. public function getValueForTargetText($richText): ?string {

J'ai réactivé le backtrace, j'obtiens le log en PJ après 2 test. php-errors.log

btry commented 3 years ago

Le correctif est pour un autre problème que j'ai trouvé en cherchant votre souci. J'en suis encore à chercher les indices pour comprendre comment on en arrive au message d'erreur.

Le fichier php-errors.log ne contient pas de backtrace, seulement des warnings lancés par GLPI, à priori pour un autre problème.

btry commented 3 years ago

Pour le bug cité ici https://github.com/pluginsGLPI/formcreator/issues/2127#issuecomment-784979798 ça ne doit pas arriver. Il ya 2 dates toutes les deux issues d'une même donnée. Or une est NULL et l'autre contient bine une date. Si je remonte à la version 2.11.0, le code ne permet pas cette erreur. Vous avez peut être des modifications dans le plugin.

amongreville commented 3 years ago

Aucune modification en dehors de la mise à jour 2.11.2 et du backtrace.

Je viens de repartir de la version 10.0.0, et je n'ai plus l'anomalie. Je vais tester chaque mise à jour.

La zone temps de résolution ne se remplie pas de la même manière entre la version 10 et 11... Capture-temps

j'avais un problème équivalent avant quand je précisais un gabarit de ticket Capture-gabarit

amongreville commented 3 years ago

Aucune anomalie jusqu'à la version 2.10.4. L'anomalie apparait dès la version 2.11.0 Ce n'est pas lié au nouvelle zone SLA et OLA qui apparaisse dès la version 2.11.0 ? Nous n'avons pas activé de SLA sur notre site. 2.10.4 : Capture-2-10-4

2.11.0 Capture-2-11-0

btry commented 3 years ago

Vu qu'on manipule des dates avec les SLA et OLA, c'est possible. Il faudrait voir si vous utilisez ces champs dans vos tickets cobles ? Pour ma part ils sont vides dans le formulaire que j'ai créé pour les tests.

amongreville commented 3 years ago

Initialement : J'ai sélectionner "depuis le gabarit ou aucun"

j'ai essayé avec une SLA spécifique, l'anomalie persiste.

De même en appelant un gabarit.

amongreville commented 3 years ago

Bonjour, Je retrouve la même anomalie en 2.10.4 si je sélectionne un Gabarit de tickets.

amongreville commented 3 years ago

Je n'ai plus l'anomalie en version 2.11.2, si je défini un gabarit de ticket sans pré-remplissage de la date d'ouverture.

btry commented 3 years ago

Bonjour

Toutes ces informations ne m'aident pas à trouver comment reproduire. Dans votre post initial, vous dites que créer un formulaire avec un ticket cible suffit à reproduire. Donc vous créez un formulaire sans section ni question vous arrivez à reproduire le bug ?

amongreville commented 3 years ago

Bonjour,

Pour reproduire l’anomalie, il faut définir en champ prédéfini, la date d’ouverture avec la valeur « Maintenant ». [cid:image003.jpg@01D70E8A.C42F0310]

amongreville commented 3 years ago

Bonjour,

Pour reproduire l’anomalie, il faut définir en champ prédéfini, la date d’ouverture avec la valeur « Maintenant ».

capture-form PNG

amongreville commented 3 years ago

Ma description, n'est pas complète : Pour reproduire l’anomalie, il faut définir en champ prédéfini, la date d’ouverture avec la valeur « Maintenant » dans le gabarit appelé dans la cible.

btry commented 3 years ago

Ah, donc en fait le bug est lié à la gestion d'un gabarit de ticket !

Je tente de reproduire.

Une astuce pour les prochains bugs. Quand vous en rencontrez un essayez d'isoler le bug en créant un formulaire le plus simple possible. Moins il contient de choses plus on peux cerner le bug facilement.

amongreville commented 3 years ago

Jusqu’à la version 2.11.*, pour ne pas rencontrer l’anomalie, je ne rattachais aucun gabarit.

J’ai donc créé un gabarit spécifique pour les formulaires sans date d’ouverture prédéfinie.

btry commented 3 years ago

Essayez ce patch, ça devrait mieux fonctionner.

amongreville commented 3 years ago

Merci beaucoup ! Le test est concluant.

Le ticket peut-être clôturé. 👍

btry commented 3 years ago

Merci, le patch sera dans la prochaine release.