Merci pour ton analyse,
c’est étrange comme comportement que le search d’une référence fasse perdre le copyId du parent.
J’aurai pensé à un problème au niveau du populate de l’objet parent au moment de sélectionner.
On va regarder ce cas d’usage de plus près, il doit y avoir quelque chose qui change le contexte du parent.
Vu c’était bien caché, en fait cela fait suite à une évolution qui doit dater de la V5 :
Quand on passe par une recherche de référence, le front envoie les valeurs en cours de saisie sur la UI et le back valorise les champs de l’objet parent en mémoire, ceci afin de pouvoir récupérer ces valeurs pour un filtrage éventuel : typiquement au niveau de l’initRefSelect en fonction des parent values en cours de saisie et pas celles en base.
Ce traitement, qui vise à être stateless en remettant le parent dans le bon contexte lors d’une recherche de référence, perd effectivement le copyId… on va corriger.
Super merci François, un mystère résolu 
Au sujet de cette évol, jusqu’ici j’utilisais des paramètres pour passer les valeurs non encore enregistrées du front au back, ce n’est plus nécessaire ?
Oui, les valeurs UI sont envoyées dans le getParentObject() côté back pour les instances qui servent à la sélection d’un objet lié :
Car on avait trop souvent besoin de filtrer ces popup en fonction de choses déjà saisies sur le formulaire.
On doit toujours passer par des paramètres par code pour mémoriser les cas où on change d’écran sans avoir de “parent” (on ouvre un panel de panel… on vient de tel ou tel écran…) et qu’on veut s’en servir plus tard pour changer de comportement en aval.
Release installée, le problème a disparu, merci !
This topic was automatically closed 60 minutes after the last reply. New replies are no longer allowed.