Lorsque je fais une recherche sur l’objet SubPurposeTags et que je sélectionne un PurposeTags comme élément de filtre, je constate que les filtres sont dupliqués sur deux champs de l’objet FamilyTags. Cela fausse logiquement les résultats de la recherche.
NB: A l’inverse je ne constate pas ce comportement lorsque je sélectionne un FamilyTags
Est-ce un comportement attendu ou s’agit-il d’un bug ? Si c’est un comportement attendu, comment puis-je configurer mon modèle ou mes recherches pour éviter cette duplication des filtres et obtenir des résultats corrects ?
Merci d’avance pour votre aide et vos éclaircissements !
Votre modèle est assez complexe car mélange des notions d’héritage, une réflexive héritée et des relations entre enfants. J’ai du mal à voir s’il induit une ambiguïté de nommage de certains champs ramenés plusieurs fois dans l’objet.
Il faut vérifier les nommages des champs et leur unicité une fois “compilés”, les filtres s’appliquent sur les field.getFullInput() = le nom logique concatène le chemin des références jusqu’au nom du champ : en back fk1.fk2...name en front fk1__fk2__...name.
mettez une AppLog dans le postLoad de SubPurposeTags pour lister tous les getFullInput des champs et voir si certains sont en doublons / ceux qui partagent le filtre
regardez au debugger de votre navigateur la requête Ajax du search pour voir les filtres envoyés et le nom du champ correspondant, il est peut être ambiguë.
Si tout est bien identifié de manière unique c’est que Simplicité ne doit pas bien retrouver le champ dans votre objet, et il faudra améliorer l’algo en front ou en back.
En effet je l’ai pas mis mais surtout j’ai envoyé le search de l’ouverture de la popin de sélection et pas la recherche après que les filtres ont été positionnés après sélection.
J’en profites, j’ai pas trouvé la configuration qui me permettrait de retirer cette loupe (demande du métier en attendant la correction de ce comportment). Je l’ai fait avec JS dans le hook front displayList mais j’avais l’impression que c’etait configurable,aurais tu des recommendations/indications sur ce sujet afin de coller au plus près du standard ?
On ne peut pas sélectionner un objet si on n’a pas de droit de lecture sur cet objet lié.
Sinon ce n’est pas prévu côté front, car c’est sensé fonctionner si on a les droits.
Masquer ce bouton reste un contournement temporaire.
La fonction “loupe de recherche d’une référence” a changé de comportement en V6.3. Il est maintenant possible de choisir plusieurs références, et seul le champ recherché sera renseigné
par une égalité stricte ou un in(...)
et non plus par la foreign-key + tous les champs liées, ce qui était ambiguë dans votre cas de lien réflexif sur 3 niveaux
On va backporter temporairement cette fonctionnalité en 6.2 mais toujours en “mono-sélection”, ça devrait corriger votre problème.
Note La 6.2 est désormais en maintenance court-terme, il va falloir envisager de passer en 6.3 LTS.
si on a le droit en lecture sur objet lié A = loupe présente sur liste d’objet B.
le passage en 6.3 devrait donc corriger le comportement que je rencontre actuellement.
Mais si j’avais cette demande de quand même masquer cette loupe, tout en gardant la saisie de texte dans l’input de recherche et sans modifier le droit en lecture, ca ne serait pas possible sans utiliser un contournement, c’est ca ?
Par exemple,est-ce que je pourrai retirer ce droit sur objet A lors de l’affichage en liste de l’objet B afin que le user est quand même accès en lecture sur l’objet A lorsqu’il clique sur l’entrée de menu ?
La 6.2.22 contiendra le changement de comportement comme indiqué plus haut.
Si on retire le droit de lecture sur l’objet lié, on ne pourra pas non plus taper dans l’input ramené = aucune recherche de référence par complétion = recherche dans l’index fulltext via une présentation en dropdown. Les droits en back s’appliquent à tous les modes de recherche en front.
Pour retirer la loupe, il faut juste ajouter du CSS à l’objet pour la masquer, mais c’est contre intuitif pour l’utilisateur (surtout dans un contexte d’accessibilité RGAA) qui ne va pas comprendre sans aide que c’est une référence recherchable uniquement par focus/input/complétion.
