J’ai un comportement que je n’arrive pas à comprendre ni à expliquer, malgré mes recherches :
J’ai un objet avec 61 ObjectFields. J’ai commenté tout le code java de l’objet pour être certain que le problème ne vienne pas de celui-ci : il ne me reste qu’un initUpdate dans lequel je rend obligatoire deux champs : un champ numérique (achNumSibo), et un champ de type Document (achJustifCommande).
Lorsque je prend un objet existant et que j’ouvre son formulaire, j’efface le contenu du champ achNumSibo, et je renseigne le champ achJustifCommande :
A l’enregistrement, j’ai alors un message d’erreur me demandant de renseigner le champ achNumSibo, ce qui est normal car ce champ est obligatoire. Notez que le champ achJustifCommande est bien renseigné :
Je renseigne alors le champ achNumSibo, puis je réenregistre. L’objet est bien enregistré, mais le champ achJustifCommande a été réinitialisé (1/ si le champ est vide, tout en étant obligatoire, je ne comprends pas comment l’objet a pu passer le validate() avec succès ; 2/ le champ n’aurait pas du être vide, car avant que je clique sur enregistrer, le champ était bien renseigné) :
J’ai parfois le message d’erreur : “WARN|designer|com.simplicite.util.engine.ObjectManager|historize||Evénement: Empty path for document 0” dans les logs lorsque j’enregistre pour la 2e fois (une fois que je renseigne le champ achNumSibo).
A cause du message d’erreur ci-dessus, j’ai essayé de désactiver l’historique de l’objet, puis d’effacer l’objet historique correspondant et de le regénérer, mais ces deux manipulations n’ont rien donné. (le message d’erreur disparait néanmoins).
Lorsque j’essaie sur un objet “plus petit” (= moins de 10 champs), j’arrive bien à sauvegarder mon objet, et le fichier est conservé lors du 2e appui sur le bouton “Enregistrer”. De même, sur la démo, sur un objet “plus petit” (= moins de 10 champs), le fichier est conservé lors du 2e appui sur le bouton “Enregistrer”. Les objets sur lesquels j’effectue les tests m’ont l’air identique (hormis le nombre de champs) et les champs sont paramétrés de la même manière.
Lors de certains cas de tests, j’ai l’impression que le fichier est bien conservé (sur mon objet “Achat” de départ). Mais je n’arrive pas à reproduire ce phénomène de façon récurrente (j’ai réussi 2 fois, sur des dizaines et dizaines de tests…)
J’ai essayé d’effacer/recréer le Field et l’ObjectField achJustifCommande, sans résultats…
Ce ne serait pas une solution, j’en suis conscient, mais : j’ai essayé de sauvegarder le fichier dans le prevalidate dans le répertoire temporaire pour conserver le fichier en cas d’erreur (champs obligatoires non renseignés par exemple ?), dans le cadre de mes tests, mais cela n’a pas abouti…
Le problème viendrait-il du fait que le fichier n’est pas conservé assez longtemps ? Auriez-vous des idées d’où pourait venir ce phénomène ? Ou bien des pistes que je pourrais explorer afin de résoudre ce problème ? J’ai l’impression d’avoir regardé partout…
A priori dans un formulaire, un champ document de type <input type="file"> doit
soit se remettre à vide, et vous devriez avoir une erreur de document obligatoire s’il n’est pas re-renseigné.
soit garder le document précédent en mémoire et le reposter correctement
On va regarder en V4 pourquoi le fichier “se perd” après une première erreur et retour sur le formulaire. Le nombre de champs ne semble pas être lié mais peut changer le temps de traitement de lecture des champs vis à vis d’un traitement asynchrone, rendant ce dysfonctionnement aléatoire.
Merci François. Est-ce que ça veut dire que le champ sera forcément vidé ? Ou bien il sera renseigné avec le même fichier qu’avant l’échec du validate() ?
Dans nos tests, le document reste bien renseigné en front suite à une erreur et s’enregistre plus tard.
Mais s’il se vide pour une raison encore inconnue dans votre cas, le back retournera bien une erreur.
D’accord merci, je vais attendre le prochain build pour tester déjà.
Sinon, lorsque vous dites :
Le nombre de champs ne semble pas être lié mais peut changer le temps de traitement de lecture des champs vis à vis d’un traitement asynchrone, rendant ce dysfonctionnement aléatoire.
C’est une supposition ou une certitude ? Si le traitement est trop long, le champ pourrait être vidé ? C’est bien ça ?
Suite à la mise à jour de notre côté, j’ai repris mes tests. J’étais encore confronté à cette erreur après la mise à jour (cf. mon 1er message pour la description de mon erreur). J’ai donc déconstruit mon objet de tous les côtés, élément par élément, afin de trouver d’où venait l’erreur.
Après analyse, je crois donc qu’il s’agit d’une anomalie : lorsque mon objet possède une contrainte de type BACK (ou BACK + FRONT), alors le document est perdu lors du premier enregistrement, qui échoue.
Je peux donc maintenant reproduire le cas sur la démo. Sur l’objet CRMContactAction, j’ai rajouté la contrainte suivante :
Après un vidage de cache, je peux reproduire l’anomalie de mon premier message (effacer le champ “Quand”, puis renseigner le champ “Document” avec un fichier, enregistrer une première fois. Après l’échec de l’enregistrement, renseigner le champ “Quand”, enregistrer de nouveau. L’Action est enregistrée, sans modifier le champ “Document”. NB : si le champ Document est obligatoire, l’action est enregistrée, mais le document a disparu, alors que le champ est obligatoire).
Me confirmez-vous cette fois-ci que vous reproduisez également de votre côté ?
Votre version date du 7/11, la release a eu lieu de 8/11 pour la V5, mais la release V4.P25 a généralement lieu dans la foulée… vous ne devez pas avoir installé le dernier patch.
5.1.12 (2021-11-08) {#version-5.1.12}
Backported flexibility on naming of the URL token parameter
Ignored cross-domain error in $ui.getTop
Fixed validate during a reset of required document
On est en auto-upgrade, et on vient de forcer l’upgrade ce midi au cas où, mais dans le menu exploitation, ça n’a pas l’air de changer la date de la release, qui est encore au 7/11 (ce qui explique pourquoi j’ai encore l’anomalie)…
On ne builde pas la 4.0 maintenance à chaque commit. Il y a eu un build ce matin, forcez la mise à jour (ou attendez demain si vous êtes en auto-update). Vous aurez alors la révision la plus à jour.
Cela dit, le build précédent datait du 7 novembre il embarquait donc bien le commit “Fix validate on reset of required document” daté du 3 novembre => @Francois le pb est donc sans doute autre chose que ce que ce commit à corrigé.
Merci pour les réponses. On a mis à jour avec la dernière release, et j’ai toujours le problème, sur l’instance de démo, avec la même manipulation.
nb : @François, une petite nuance avec votre vidéo : je ne dis pas que les champs de type document sont vidés s’ils étaient renseignés avant l’enregistrement - le cas que vous montrez. Je dis que si on part d’un formulaire avec un champ document vide, qu’on le renseigne, qu’on fait échouer le validate avec un premier enregistrement, puis qu’on réenregistre cette fois-ci avec succès, alors le document est perdu, comme dans la vidéo suivante : Echec validate.zip (5.0 MB)
De plus, si le champ document est obligatoire, mon objet est sauvegardé malgré tout…
Peut-être avez vous également testé mon cas, mais que vous ne reproduisez pas non plus, mais ce n’est pas grave, j’ai enlevé les contraintes de type back que j’avais sur l’objet, je rajouterai si besoin le code correspondant directement dans le prevalidate : ça marche bien comme ça !
