Dans un objet métier « Documents », nous avons 2 attributs de type liste de valeur « Menu concerné » (A) et « Type de document » (B). Pour chaque valeur de la liste A nous avons une liste liée de la liste B.
Ces 2 attributs d’objets sont de type « Group by ».
Les listes liées s’affichent correctement quand on effectue une recherche sur la liste de l’objet métier :
Exemple : Quand on sélectionne « Contrat » dans A, seules les valeurs de la liste liée à « Contrat » s’affichent dans B.
Par contre, quand on effectue une recherche dans une liste de document de dessous (un objet NN, exemple Documents/Bail), la sélection d’une valeur dans A (champ maître) ne limite pas les valeurs de B aux valeurs de la liste liée associée à la valeur de A. Exemple pour la valeur « Contrat » :
Est-ce que c’est normal ? Aurais-je oublié de paramétrer qq choses ?
Enfin, serait-il possible de proposer un affichage en dynamique des valeurs d’une liste de valeur ? Je m’explique : lors d’une recherche, afficher dans la liste de valeur seulement les valeurs qui existent dans la liste sur laquelle on effectue la recherche ? c’est-à-dire, si dans ma liste ne se trouve aucune occurrence pour « Contrat », la valeur « Contrat » ne sera pas proposée dans la liste de valeur.
Liste liée en recherche panel : il doit y avoir un oubli de refresh de liste liée dans le cas d’une liste fille. on va regarder si cela avait été fait sinon on va l’ajouter, car ça doit pas être compliqué à reproduire.
Masquer les ENUM de recherche sans record = cela revient à calculer des count par type avant affichage de la recherche (pour savoir si égal à 0), donc ça couterai cher en SQL mais serait effectivement intéressant à afficher “Libellé (quantité)”.
En général on n’indexe pas les ENUMs dont cela ferait un full scan pour chaque ENUM, peu performant dans un cas général, il faudrait donc le limiter à certains ENUMs paramétrables (et indexés pour que le count soit très rapide = count de l’index et pas de la table).
Je ne reproduis votre problème 1) sur une 4P25 à jour ni sur un 5.1.
La liste liée est bien rechargée, par exemple sur la Démo / listes des contacts d’un client, entre le type et le sous-type :
Je ne vois pas si ce sont bien des ENUM simples et pas à choix multiples.
Présence de contrainte ou de code front ?
Hook initList ou autre qui accède à ces champs ?
Trace dans la console ?
Quand on sélectionne le premier filtre, la liste se rafraichit avec le filtre, et la liste liée est également rechargée. Vous devez être dans un cas particulier où il n’arrive pas à appliquer la liste liée et prend la liste “full” qui fait l’union de toutes les listes.
Pouvez vous nous donner un accès pour qu’on passe le code front au debugger ?
J’ai fini par comprendre en analysant votre modèle, en fait les listes liées ne s’appliquent bien qu’aux champs de l’objet et ses héritiers.
Dans votre modèle, cela fonctionne donc sur votre objet Document (du menu) qui possède un type/sous-type, mais pas sur ces 2 champs ramenés dans l’objet de relation N,N Document <—> Bail (ou autre) accessible dans le panel Document du Bail (le titre de l’onglet identique m’avait induit en erreur car ce n’était pas le Document en relation directe 0,N, comme le Contact de la Démo en lien direct avec un Client qui fonctionnait bien).
On a fait l’évolution pour que les listes liées se chargent aussi si les champs sont ramenés, car même si cela ne sert à rien dans la création/mise à jour de la N,N (champs liés ramenés par référence non modifiables), cela peut servir dans la recherche.
Pour le “count” par type, on ne le fera pas à ce stade, car un besoin similaire a déjà été ajouté au backlog V5 = compter les ENUM placés dans le menu (comme les états qui sont déjà comptés).
