Problème d'affichage sur la création depuis le panel de lien

Bonjour,

J’ai un bug d’affichage très particulier avec un objet uniquement sur l’écran create (pas sur le update ni le copy).
Voici mon modèle :

Le problème d’affichage on create est sur l’objet testObjComponant :

au lieu de m’afficher le name du parent du child, j’ai deux fois le name du child; quand je suis sur l’ecran update l’affichage se fait bien comme il faut :

Je suis en simplicité 5.1.39 Bootstrap 4

Zouhair

Bonjour Zouhair, ça faisait longtemps :slight_smile:

J’ai l’impression que c’est juste un problème d’affichage du populate, il se mélange les pinceaux entre les champs de même nom.

  • Quand tu enregistres la création, est ce que l’affichage est alors correct ?
  • En update, si tu sélectionnes une autre parent, est ce que ça fait pareil ?

De mémoire le picker / populate UI renseigne les champs du formulaire dont la FK matche avec l’objet sélectionné. Le nom absObjName doit être ambiguë car ramené 2 fois.

Yes ça fait un bail; ravi d’être de retour dans la communauté :slight_smile:

Voici les réponses à tes questions :

  • Quand tu enregistres la création, est ce que l’affichage est alors correct ? L’affichage est correct après le save
  • En update, si tu sélectionnes une autre parent, est ce que ça fait pareil ? oui, quand je sélectionne un autre parent, le bug est reproduit

Ok c’est donc un bug front du $ui.populateReference qui n’est pas assez précis sur les champs à renseigner s’ils ont le même nom (mais pas le même full name).

Peux-tu m’envoyer ton module pour reproduire ton cas ?

Problème corrigé sur le service Ajax populate.

La méthode populateForeignKey a été revue pour ne plus être permissive sur la syntaxe des champs.

En V3, on pouvait donner des noms partiels aux champs ramenés et cette méthode était “lazy” et prenait le premier champ qui “ressemblait” à un champ parent, ce qui expliquait l’ambiguïté sur ton cas.

Désormais en V5 (et depuis la V4), comme on utilise des full-inputs partout (nom complet qui identifie bien chaque champ fkX.fkY.(...).name), il ne devrait plus y avoir d’ambiguïté si un champ est ramené 2 fois au travers de références en cascade (comme ici fkX.fkY.name et fkX.name).

Ce sera poussé en 5.1.41.

ps : ce cas n’a jamais été remonté en V4, où on s’en sortait avec la surcharge du nom (via le champ “Input/Tag” dans l’attribut d’objet pour faire les correspondances).