J’ai vérifié, il n’y a pas de contraintes correspondant sur l’objet Centre ou Examen.
J’ai l’impression que ça coince au niveau de l’ID du centre, qu’il n’arrive pas à faire la liaison entre le nom et son ID, je ne sais pas…
J’ai aussi vérifié dans la BDD, la valeur n’a pas persisté, ce n’est donc pas un problème côté front.
Si besoin, voici les deux attributs du centre dans l’objet Examen:
Je ne vois rien d’anormal avec les éléments transmis.
Vous devez avoir un pb de paramétrage dans vos attributs d’objet, comme des champs en double / déclarés 2 fois dans l’objet à des ordres différents, ce qui peut provoquer des problèmes de mapping avec la UI.
Regardez si votre FK et ses champs joints sont bien associés une seule fois à votre objet.
c’est pas très conseillé de mettre une FK après ses champs ramenés (ordre 400 vs 20)
il y a 2 fois l’ordre 30 ce qui rend indéterminé dans quel ordre la UI va afficher les 2 champs en liste
Sur le pb d’origine :
ou alors 2 champs avec un même nom physique ?
y a-t-il du code dans l’objet Centre, du genre qui positionne des filtres de visiblité (search-spec ou autre suivant l’instance, dans le initRefSelect…) ?
De ce que vous décrivez en front le picker vous permet de sélectionner un centre, mais au “save” en back il disparait.
En back, Simplicité refait le contrôle que l’utilisateur a bien le droits de sélectionner ce objet, sinon il force la FK à null.
Vous pouvez ajouter des traces dans le preValidate pour voir ce que contient la FK.
Si c’est vide c’est qu’une règle/filtre retire ce choix entre la UI et le back
Sinon c’est que la table a un problème pour persister cette colonne (ce n’est pas un integer).
mais vous devriez voir une trace d’erreur SQL dans les logs (avez vous regardé les logs ?).
Enfin, essayez de supprimer le champ et de le recréer sur une autre colonne physique.
j’ai repositionné mes champs de manière cohérente (FK AVANT ses champs ramenés)
J’ai réattribué les ordres correctement sans doublon
Pour le moment je laisse les champs non mappés dans une zone tels qu’ils sont, mais je note le point pour les repositionner ultérieurement
Sur le pb d’origine:
A la base, il y avait effectivement un champ “Nom Centre” mais en champ libre (cf. mon dernier screen, premier sur la liste “namExaCentre”). Je l’ai supprimé, ainsi que sa colonne dans la BDD pour ne pas créer de confusion. Pb toujours présent
Il y a un peu de code dans l’objet Centre. Je l’ai mis en commentaire mais le problème persiste. Je laisse tout de même en commentaire pour le moment en attendant de poursuivre mes tests
Effectivement, c’est lors du “save” que la valeur du champ disparait. J’ai donc fait ce que vous m’avez suggéré, j’ai ajouter des traces dans le preValidate pour voir ce que contient la FK, et elle est effectivement vide. Et il n’y a aucune erreur de type SQL ou autre dans les logs depuis le début…
Il y a donc probablement un souci au niveau d’une règle/filtre, mais où? Je poursuis mon investigation…
Vous pouvez aussi debugger le flux sortant de la UI (onglet network du debugger chrome) au moment du “save” pour voir quelles données sont envoyées au back dans le call xhr.
Sinon autant supprimer ces champs de l’objet + la colonne physique de la FK, et les recréer proprement à partir de 0 via l’éditeur avec des noms un peu différents pour être sûr de tout recréer, ça prend 5 minutes. Il doit trainer quelque chose de vos anciens paramétrages.
Ou réinstaller sur une autre instance Simplicité vierge votre module, vous verrez si cela vient de votre environnement.
Alors j’ai supprimé les champs nom et id + les colonnes physiques. J’ai recréé “au propre” mon attribut en donnant un différent nom pour être sûr que la plateforme de confonde pas les attributs entre eux.
J’ai débuggé le flux comme suggéré. En sélectionnant ma ligne dans le picker, j’ai effetivement mes deux champs qui sont populés:
Je vais créer une nouvelle relation avec un autre objet quelconque, reproduire la manipulation et voir ce que ça donne. Si ça fonctionne, c’est bien un souci entre mon objet Examen et mon objet Centre. Sinon, on est sur un souci au niveau de l’environnement en général.
Je vais aussi tester mon module sur un autre environnement et voir ce que ça donne.
Je vous tiens au courant. En attendant, si vous avez d’autres pistes je suis preneur
Dans Simplicité il y des cas 0,N partout et qui fonctionnent, donc je ne comprends pas votre cas de paramétrage. En utilisant les wizard ou l’éditeur de template, on ne peut pas se tromper.
Sur votre objet Examen :
comme déjà indiqué, vos 2 champs “Centre” ne sont pas dans une zone du formulaire et donc non lu/accsesible lors du $ui.readForm qui récupère les valeurs. Pourtant on voit que le champ Centre est bien aligné dans le template HTML sans être déclaré comme faisant parti de cette zone / commencez par ça
ou une contrainte de type Front ?
Resource JS avec des hooks front ?
Code en dur dans les template HTML ?
Vous pouvez debugger pas à pas le $ui.readForm pour voir pourquoi il est ignoré.
Alors pour le debug, c’est la foreign Key (namExaCntIdFk) de l’objet Centre qui est ignorée, la valeur n’est pas prise en compte dès le _call. Du coup, cette même FK n’y est pas dans le readForm. Le nom du centre (namExaCntIdFk_namNomCentre) lui est bien pris en compte mais bien entendu il n’arrive pas à se lier à son ID puisqu’il n’y es pas et donc il se supprime lors du save/update.
Ce que je ne comprends pas, c’est que lors de la sélection dans le picker, l’ID est bien récupéré dans la response de l’xhr.
J’ai déjà eu des attributs et des pickers qui n’appartenaient pas à une zone d’attribut spécifique par le passé, ça n’a jamais posé problème. Ou en tout cas pas ce genre de problème.
J’ai testé sur un autre environnement, et c’est le même problème.
J’ai tenté de déplacer le picker sur une autre zone d’attribut, idem.
J’ai même créé une relation avec un différent objet pour voir si le souci venait de mon objet Centre en lui-même ou si c’était plus général. Le même problème est reproduit avec l’objet testé
J’ai comparé le paramétrage de mon picker qui ne fonctionne pas avec un autre qui fonctionne, il n’y a aucune différence apparente.
J’ai passé mes champs nomCentre et son id à obligatoire pour voir ce qui se passe. Au save, Il me rejette en m’indiquant que l’Id doit être rempli. C’est bien lui qui passe à vide et empêche la persistance dans la BDD.
En effectuant tous ces tests, j’ai supprimé le peu de code qu’il y avait dans Examen et centre, que ce soit java ou JS, j’ai supprimé toutes les contraintes de ces objets bien qu’elles soient appliqués sur d’autre champs histoire d’être sûr.
Je dirais selon moi que le souci vient soit de l’objet Examen (un paramétrage manquant/a faire), soit de ma relation d’objet elle même…
Impossible de vous aider dans le noir, de ce que vous indiquez je ne vois strictement rien d’anormal au niveau paramétrage. Il faudra nous envoyer votre module pour analyse à support@simplicite.fr ou alors nous donner un accès à votre instance dans un MP.
Nous avons reçu vos modules, nous allons monter une instance de test en les y chargeant.
Pouvez vous préciser :
la version exacte de Simplicité que vous utilisez, c’est indiqué (par exemple) en appelant le /health de votre instance, ex:
la base de donnés (type et version)
NB: Pour la version Simplicité nous déploieront une version à jour dans tous les cas, si vous n’êtes pas à jour mettez vous à jour car nous considérons, par défaut, que vous êtes toujours à jour quand vous sollicitez notre support.
OK merci de commencer par vous mettre à jour. C’est le prérequis pour solliciter notre support.
En l’occurrence je doute que ça change quelque chose sur votre cas (qui est sans doute un cas particulier/subtil de paramétrage/code spécifique) mais, de toute façon, nous n’investiguons les problèmes qu’on nous remonte que sur une version à jour.
Ce n’est vraiment pas pour vous embêter, c’est pour éviter à tout le monde de perdre du temps sur des choses qui ne sont potentiellement plus d’actualité.
Merci, c’est bien un problème de paramétrage de l’objet.
Le problème vient du fait que la FK (input hidden) n’est pas dans le formulaire affiché.
Dans votre cas, certains champs sont directement mis sur le template de l’objet (pas dans une zone d’attributs), et les champs manquants ne sont pas ajoutés car hors zone.
Ajoutez le champ FK dans le template de l’objet (il sera en hidden) en dessous de votre champ Centre, il pourra contenir le row Id sélectionné de la UI.
De manière générale, comme dit plus haut :
il faut toujours assigner ses champs dans des zones d’attributs et dans un template. On peut ne pas mettre un champ caché dans le template d’une zone (Simplicité l’ajoute à la fin de l’area)
et il faut grouper dans les attributs d’objet la FK de ses champs joints pour plus de clareté.
Dans votre paramétrge, le FK est en position 500 (en dernier) et le libellé en position 5 (en premier).
Simplicité peut ajouter les champs non mappés dans le HTML dans leur zone d’attributs (à fin dans un zone fourre tout). On pourrait faire une évolution pour compléter les champs non mappée au niveau du template principal.
@Francois: J’ai testé et ça a fonctionné… Il n’y avait effectivement pas ce champ FK caché dans le template, ce qui empêchait la plateforme de faire le lien, croyant que la simple présence de l’attribut au sein de l’objet serait nécessaire. Du coup j’ai associé mes champs à une zone d’attribut et remonté ma FK en position 10 pour plus de clareté.
Encore merci pour votre support et votre réactivité.
