Filtre de la liste de deuxième niveau mal mis à jour lorsque le champ accepte plusieurs valeurs

[acheype]

Lorsqu'on a des listes à deux niveaux, on s'attend à ce que les choix du niveau 2 soit réduit par rapport à la sélection faite par le niveau 1. Cela fonctionne actuellement bien quand on a pour chaque fiche qu'une valeur pour les champs de niveau 1 et 2, mais lorsqu'il y a plusieurs valeurs possibles (c'est à dire si les champs sont de type checkbox ou checkboxfiche), le filtrage propose certaines valeurs pour le niveau 2 qui ne sont pas liées au valeurs sélectionnées de niveau 1.

Voici un exemple concret où les fiches sont des associations et le niveau 1 et 2 sont respectivement les champs « Catégorie(s) » et « Sous-catégories » et chaque champ peut contenir plusieurs valeurs. Le lien entre catégorie / sous-catégorie est correctement respecté à la saisie. Exemple avec ce screenshot où les sous-catégories affichées sont bien celles de « Lieux ressources et multiactivités » :

Mais lors de l'affichage de la liste des associations, les sous-catégories affichées pour le filtrage sont trop nombreuses. Cf screenshot ci-dessous avec la même sélection au niveau des Catégories :

Ca me semble dû au fait que les facettes sont affichées qu'en fonction des valeurs existantes et pas en se basant sur les liens entre niveau 1 et 2 comme le fait l'interface de saisie. Dans cet exemple, si on a en effet une association avec comme catégorie "Lieux ressources et multiactivités, Catégorie Supplémentaire" et comme sous-catégories "Centres sociaux, Sous-catégorie sup1, Sous-catégorie sup2", ces deux dernières sous-catégories vont s'afficher bien qu'il n'y a aucun lien entre « Lieux ressources et multiactivités» et « Sous-catégorie sup1 » ou « Sous-catégorie sup2 ».

J'espère que ce sera corrigé et qu'à terme on aura ce module d'intégré dans le cœur de yeswiki car je trouve ces 2 niveaux de filtrage répondent bien à un besoin souvent évoqué et que c'est finalement assez simple à configurer (autre avantage, il permet de refactorer le vieux code qu'utilise les facettes).

[J9rem]

@acheype en fait, le comportement que tu décris est un comportement recherché en fait (mode or ou mode and) Tu décris une nouvelle demande qui serait que pour le paramètre intrafiltersmode="or" nous puissions avoir un autre mode en plus de or ou and, mais aussi le mode sublevel. Est-ce bien ceci ?

Pour que ce mode fonctionne, il faut que dynamiquement, le javascript aille rechercher la liste des liens niveaux 1 - niveaux 2 en base de données puis rafraîchisse la liste des facettes en conséquence, ..... c'est un peu plus lourd que ce qui est fait actuellement. Je vois plutôt ceci dans un autre développement pour lequel il faudrait trouver le financement.

En attendant, je ne vois que la solution d'avoir un niveau 2 de type radio ou liste (mais a priori, ça ne correspond pas au besoin)

Pour la question de l'intégration dans le cœur, je pense que le besoin est assez évident. Il existe des visions très différentes de stratégies de mise en œuvre de ce besoin et la solution que j'ai retenue pour cette extension ne semble pas correspondre à la stratégie adéquate pour pouvoir être intégrée dans le cœur (cf. cette PR). J'ai donc préféré partir pour une extension séparée pour laquelle je voyais comment la mettre en œuvre en sachant qu'il y a de très grandes chances qu'elle ne soit pas intégrée dans le cœur.

[acheype]

Merci @J9rem pour ta réponse. Si je comprends bien comment fonctionne le paramètre intrafiltermode, le or est le comportement qui existait déjà et qui fait que chaque filtre ajouté - dans une même facette - s'effectue avec un OR dans recherche SQL tandis qu'avec le mode and, cette recherche est effectuée avec des AND.

Pour moi, ce paramétrage est indépendant du fait de vouloir contraindre les valeurs de la liste de niveau 2 à celle du niveau 1. Et je ne vois pas de cas d'utilisation réel qui n'aurait pas besoin de contraindre ces valeurs : si à la saisie cette contrainte existe, à l'affichage cela me paraît important qu'elle soit toujours respectée. As-tu un exemple concret à me donner où ce se ne serait pas le cas ?

Ce que j'ai l'impression c'est que dans un cas où l'utilisateur saisie qu'une valeur pour les niveaux 1 et 2, les filtres affichés restent cohérent et c'est certainement le cas d'utilisation pour lequel tu as développé ce module. Mais qu'avec plusieurs valeurs possibles, c'est à dire l'utilisation de « checkbox », l'affichage des filtres n'est plus cohérent. Le cas détaillé ci-dessus est simplement un exemple.

Et oui je comprends bien que ça nécessite un peu plus de dév pour gérer ce cas et qu'un financement serait nécessaire. Et si j'ai bien compris le fonctionnement, mieux vaut juste prévenir que le module ne fonctionne pas à l'affichage pour les champs de type « checkbox ».

Pour la question de l'intégration dans le cœur, je vais plutôt en parler sur l'autre PR du coup.

[J9rem]

@acheype

Si je comprends bien comment fonctionne le paramètre intrafiltermode, le or est le comportement qui existait déjà et qui fait que chaque filtre ajouté - dans une même facette - s'effectue avec un OR dans recherche SQL tandis qu'avec le mode and, cette recherche est effectuée avec des AND.

exactement

Et je ne vois pas de cas d'utilisation réel qui n'aurait pas besoin de contraindre ces valeurs : si à la saisie cette contrainte existe, à l'affichage cela me paraît important qu'elle soit toujours respectée.

et bien ça dépend, dans certains cas, on peut vouloir faire en sorte que le département (2nd niveau) soit à choisir parmi une liste filtrée qui dépend de la région retenue (1er niveau). Ceci facilite la saisie des informations.

Toutefois, il peut très bien y avoir la volonté d'avoir un comportement de type intrafiltermode="or" pour lesquels, sciemment, on souhaite que tout s'affiche, même les départements qui ne sont pas dans les régions sélectionnées, afin de ne pas changer le comportement des filtres et rester de type or. J'ai très souvent le cas.

Pour le fonctionnement de type intrafiltermode="and", il se trouve qu'il fonctionne de façon similaire à intrafiltermode="sublevel" (filtre fictif) dans le cas de liaisons premier - second niveau de type liste ou radio. Comme le développement de intrafiltermode="and" n'a pris que quelques lignes et correspondait au besoin des financeurs, il n'y a pas eu le développement de la grosse option intrafiltermode="sublevel" (et je suis d'accord, c'est un besoin légitime que ton cas d'usage met en évidence)

Et si j'ai bien compris le fonctionnement, mieux vaut juste prévenir que le module ne fonctionne pas à l'affichage pour les champs de type « checkbox ».

très bonne idée : je vais rajouter un commit dans ce sens dans la documentation, et les hint quand c'est pertinent. Merci pour cette astuce

[acheype]

@J9rem

1) Je ne comprends pas que tu continues à parler de intrafiltermode="sublevel", pour moi c'est clairement 2 trucs différents vu que intrafiltermode traite les options au sein d'une même facette. Là, ce sont les options entre différentes facettes dont on parle, on est continue d'avoir le ET qui existe déjà entre chaque différentes facettes mais on rajoute, uniquement pour les facettes qui sont un champ de niveau 2, la contrainte que les options appartiennent aux valeurs sélectionnées des facettes de niveaux 1.

2) Pourquoi pas plutôt parler d'un autre paramètre du style linkTwoLevels="yes"... mais je ne vois vraiment pas l'intérêt à part rajouter de la complexité. Vu que les 2 champs sont liés, ça me paraît clair que ce lien ne se matérialise pas qu'à la saisie mais aussi pour le filtrage également. Supposons que ce soit des associations pour lesquels nous avons 2 champs associés : Région(s) et Département(s). A la saisie, ça me semble comme tu le dis important qu'elle soit facilitée en filtrant le champ département en fonction de la région ou des régions sélectionnées. Et à l'affichage, j'y vois exactement le même intérêt car afficher les 101 départements français pour qu'il puisse trouver le bon département sur lequel filtrer, c'est loin d'être ergonomique. Ce serait plus utilisable si à chaque fois qu'il sélectionne une région, la liste des départements se remette à jour. Si tu as un exemple pour lequel ce lien doit exister qu'à la saisie et que c'est gênant qu'il s'affiche pour l'affichage des facettes, ça me permettrait d'y voir plus clair. En tout cas pour ton exemple des régions / départements, j'y vois un gros avantage d'ergonomie.

3) [un peu à part] Avec ce module, à chaque fois qu'on sélectionne une option de facette, les options des autres options sont mis à jour. A la base, je trouvais que c'était une bonne idée... mais là en réfléchissant sur ce cas, je me rend compte que cela perturbe vraiment l'utilisateur. Il ne vaut mieux pas au niveau des logiques d'interface réinventer la roue, et mieux se baser sur des interfaces déjà existantes de sites. Par exemple, dans ce site, on retrouve bien ces différents critères (facettes) et on a comme par défaut dans YesWiki, un ET entre les options des critères et un OU entre les options d'un même critères. Mais on voit bien que suivant la sélection le nombre affiché est toujours le nombre total, bref que ce nombre ne s'ajuste pas suivant les options sélectionnées. (je n'ai pas vu de liste à "plusieurs niveaux" par contre sur le site)

4) J'en profite pour continuer l'exemple des départements, car cela donne un exemple pour le ticket peut-être plus criant. Avec une fiche association qui seraient présentes dans 2 départements, on aurait comme fiche :

• Région(s) : "Ile de France" & "Auvergne Rhône Alpes"
• Département(s) : "Val de Marne" & "Savoie"

Ainsi à l'affichage des facettes, si on clique sur "Ile de France", on a aurait ainsi les options "Val de Marne (1)" et "Savoie (1)". Bref, sans les contraintes des ces listes à 2 niveaux prises en compte, on obtient un filtrage contre-intuitif... et perso j'ai préféré l'enlever, c'est donc dommage.

5) Je conçois que vu qu'il y a des contraintes supplémentaires qu'il n'y a pas entre 2 facettes classiques, qu'il faudrait que cela puisse se voir visuellement sur l'interface des facettes. Dans l'exemple des catégories/sous-catégories, vu que je les affiche au dessus, j'ai affiché les sous-catégories en décalé... mais avec un affichage à gauche ou à droite, il faudrait trouver une autre astuce visuelle.

[J9rem]

merci @acheype , je vois que tu as plein d'idées, je garde ça au chaud pour essayer de les prendre en compte dès que je trouve du financement.

[J9rem]

Hello @acheype

a priori je pense avoir répondu à cette attente avec la version 1.3.0 de twolevels et le paramètre intrafiltermode="sublevel".

Je ne sais pas si ça répond à tous tes besoins mais je serai content que tu testes pour ton usage et que tu me dises si c'est déjà mieux qu'avant (et si tu vois d'autres effets de bords)

[acheype]

salut @J9rem, merci pour ta mise à jour !

j'ai testé rapidement mais malheureusement ça ne fonctionne pas mieux... J'ai le même comportement et pour faire fonctionner le module (j'avais une erreur du navigateur avec zéro msg côté serveur, donc dur à comprendre), j'ai dû enlevé le custom que j'ai qui cache le deuxième panneau de filtre quand aucun élément du premier panneau de filtre n'est sélectionné.

Voici en image le soucis de mise à jour du filtrage sur le champ de deuxième niveau. Côté saisie, j'ai bien l'affichage d'uniquement des sous-catégories associées à la catégorie « Loisirs » :

Et côté bazarliste, lorsque je sélectionne cette catégorie, je n'ai pas uniquement ces 3 sous-catégories mais bcp d'autres également :

Voici le code du bazar liste pour info : {{bazarliste id="4" template="card" class="asso-cards" displayfields="visual=,title=bf_titre,subtitle=checkboxfiche9bf_souscategories" entrydisplay="direct" filterposition="left" groups="checkboxfiche8bf_categories,checkboxfiche9bf_souscategories" intrafiltersmode="and" nbcol="4" pagination="20" resetfiltersbutton="1" search="dynamic" titles="Catégories,Sous-catégories" }}

[acheype]

Ah non c'est bon en fait @J9rem. C'est juste que je n'avais pas mis intrafiltersmode="sublevel". Trop bien !

[J9rem]

ah ouf, ... et bien me voilà rassuré. Est-ce qu'on clot cette issue donc ? :wink:

[acheype]

Avant de clore, je préférerais comprendre pourquoi tu as gardé cette idée de intrafiltersmode="sublevel". Comme exprimé plus haut sur mon commentaire du 16 Mai, ça n'a pas de sens pour moi de faire du OU entre des champs qui sont liées avec twolevels. Est-ce que tu pourrais me montrer des cas d'utilisation concret que tu utilises dans tes projets ? L'exemple des Régions / Département me semble également bien parlant, et si on le reprend comme j'en parlais dans le même commentaire : quand on sélectionne « Ile de France », je ne vois pas l'intérêt de continuer à afficher « Haute-Savoie ».

Et pour que je puisse utiliser la puissance de ce module dans mon projet, j'ai encore 2 trucs à régler et j'en profite pour les mettre là car j'en parle plus haut.

• c'est perturbant pour l'utilisateur de voir les labels de « Catégories » se mettre à jour quand il sélectionne une sous-catégorie (pour moi, cet essai de vouloir remettre à jour tous les labels est une fausse-bonne idée au niveau de l'ergonomie - cf le site de ldlc dont je mets le lien plus haut qui a une bonne ergonomie avec ces filtres à plusieurs niveaux). Exemple ci-dessous qui est la suite du screenshot précédent quand on clique sur « Loisirs créatifs » :

• j'ai toujours besoin de cacher le deuxième panneau de filtre quand aucun élément du premier panneau de filtre n'est sélectionné. Or maintenant avec ta nouvelle version de _filters.twig qui fait des remplacements, je ne peux plus le redéfinir comme je le faisais dans custom avec :

  {{ include_javascript('custom/javascripts/bazar/twolevels-custom.js') }}
  {{ include([
  'tools/twolevels/templates/bazar/entries/index-dynamic/_filters.twig',
  'tools/bazar/templates/entries/index-dynamic/_filters.twig'
  ]) }}

  cela rend une réponse de type ERR_EMPTY_RESPONSE de la part du navigateur.

merci pour tes réponses !

[J9rem]

Est-ce que tu pourrais me montrer des cas d'utilisation concret que tu utilises dans tes projets ?

@acheype euh, ... je ne vais pas te présenter de cas concret mais te répondre à "comprendre pourquoi tu as gardé cette idée de intrafiltersmode="sublevel""

• dans YesWiki, le comportement par défaut est OU au sein d'un même filtre. C'est un comportement surprenant maintenant par rapport à la norme sur internet MAIS c'est le comportement habituel dans YesWiki. L'extension twolevels est une extension officielle qui peut être ajoutée par n'importe qui. C'est une extension complexe, dans le sens qu'il y a plusieurs impacts possibles et que l'usager ou l'usagère n'a pas forcément la connaissance des implications de l'installation de cette extension et peut par la suite oublier de la désinstaller. Pour éviter que le comportement soit différent d'un YesWiki standard, j'ai décidé que par défaut, le comportement n'est pas changé et qu'il faut une action motivée par l'usager, dans les paramètres avancés pour modifier ce comportement. L'idée est surtout d'éviter d'avoir des remarques de bugs potentiels liés à ce comportement alors que la personne a oublié qu'elle avait installée l'extension twolevels
• le comportement ET est le comportement qui peut servir dans la plupart des cas, sauf les cas évoqués ci-dessous

• le comportement sublevel est plus complexe (chargement de vuejs, recherche dans le DOM des associations, importations des associations), je ne l'ai pas activé par défaut pour éviter les requêtes inutiles consommatrices de ressource

  Il est possible d'activer l'option sublevel par défaut pour tous les appels de bazarliste en suivant les ajours que j'ai fait dans la doc de l'extension dans la version 1.3.2. Je pense que ceci répondra à ton besoin que ce soit activé par défaut sur ton wiki.

  c'est perturbant pour l'utilisateur de voir les labels de « Catégories » se mettre à jour quand il sélectionne une sous-catégorie

  Je n'ai pas trop compris de quoi tu parles : depuis les facettes ou depuis la saisie d'une fiche. Peux-tu préciser ?

  Or maintenant avec ta nouvelle version de _filters.twig qui fait des remplacements, je ne peux plus le redéfinir comme je le faisais dans custom avec :

  Pour ton souci de boucle infinie dans les inclusions de templates, il te suffit de mettre dans le fichier custom/templates/bazar/entries/index-dynamic/_filters.twig pour twolevels v1.3.2:

  {% if renderedFromTwoLevels %}
  {{ include('tools/bazar/templates/entries/index-dynamic/_filters.twig') }}
  {% else %}
  {{ include_javascript('custom/javascripts/bazar/twolevels-custom.js') }}
  {{ include('tools/twolevels/templates/bazar/entries/index-dynamic/_filters.twig') }}
  {% endif %}

[acheype]

Déjà merci @J9rem pour ce code et l'ajout de la variable renderedFromTwoLevels, ça m'a permis de remettre mon code custom !! et merci aussi de prendre le temps de discuter de ces points car pour moi, s'il on veut que cette extension soit utilisée, c'est important que ça soit clair et facile pour les utilisateurs.

Ok, tu veux que par défaut le comportement ne change pas de YesWiki, c'est donc plus clair pour moi à ce niveau et je comprends. Je reviens d'abord sur ce point :

le comportement par défaut est OU au sein d'un même filtre. C'est un comportement surprenant maintenant par rapport à la norme sur internet

Reprécisons déjà que le filtre entre différentes facettes est bien un ET que ça semble nous aller à tous, et que c'est ce qu'on a l'habitude de voir sur internet. Mais pour le filtre au sein d'une même facette, j'aimerais comprendre pourquoi tu trouves que le OU utilisé par YesWiki est surprenant. Si on regarde d'autres sites comme celui de la coopérative oasis avec GogoCarto, c'est ce qui est utilisé. Pareil pour le site du vendeur de pièces info que je citais plus haut. Si tu regardes cette configuration là, j'ai sélectionné pour "Type de capteur" à la fois "CMOS" et "CCD" et c'est bien un filtre OU qui est utilisé.

Ainsi il me semblerait plus clair que ce module rajoute uniquement la possibilité d'utiliser des listes à 2 niveaux et de garder le comportement par défaut de YesWiki. C'est vrai que ça ne coûtait pas grand chose d'essayer le filtre AND au sein de la même facette, mais ce dernier paramètre apporte à mon sens de la confusion, et comme ça je ne vois pas de cas intéressants pour son utilisation (tu as peut-être des exemples ?).

Actuellement sublevel fonctionne avec un ET au sein de la même facette. C'est problématique pour mon cas d'utilisation car si je reprends le premier screenshot plus haut, si l'utilisateur sélectionne "Jeux / collections" et "Loisirs créatifs", il s'attend à voir toutes les associations qui ont soit l'un soit l'autre et non les 2. C'est ce que je disais plus haut en mai sublevel devrait être défini dans une autre variable car cela se situe à un autre niveau : on pourrait très bien utiliser sublevel avec un OU ou un ET au sein d'une même facette.

Malgré ce que j'ai dis plus haut, si tu tiens vraiment à garder ce intrafiltermode, il faudrait uniquement qu'on puisse y mettre AND et OR. Après la question c'est est-ce qu'on utilise une autre variable pour gérer ce "sublevel" ? Je comprends que ce mode exécute plus de requêtes mais pour moi si l'utilisateur choisit d'utiliser cette extension et rajoute un champ "liste à 2 niveaux" j'image que les requêtes supplémentaires se font juste par rapport à ce champ "liste à 2 niveaux" et que l'utilisateur s'attend à ce que se champ à 2 niveau soit géré à la saisie mais également lors des filtrages (ça me paraît plus confusant pour lui que ce ne le soit pas à l'affichage par défaut).

Je n'ai pas trop compris de quoi tu parles : depuis les facettes ou depuis la saisie d'une fiche. Peux-tu préciser ?

Oui bien sûr, je reviens donc sur ce point : c'est bien à l'affichage depuis les facette que je parle (cf mon exemple plus haut pour l'illustrer). Niveau saisie, ce module fonctionne parfaitement. Si l'on revient aux habitudes web des utilisateurs, et j'ai l'impression qu'on est d'accord que c'est important de reproduire ce qui se fait pour que ces filtrages deviennent intuitifs, je ne connais pas de site où à chaque fois qu'on sélectionne un item du filtre, tous les autres filtres se mettent à jour. Et je comprends maintenant car ça peut être déroutant pour l'utilisateur. Là pour moi, je trouve intéressant qu'on ait essayé et je trouvais cela bien au départ, mais au final ce n'est pas convaincant. Et là pour le coup, on a un comportement activé par défaut qui change du comportement de yeswiki. Donc soit, on laisse cette possibilité et dans ce cas je suggère que ce soit géré par un paramètre non activé par défaut, ou soit on supprime complètement ce comportement. Après, je parle pour les champs classiques, pour les champs "liste à 2 niveaux", ça me paraît normal qu'il y ait un affichage dynamique afin que ce lien se matérialise et serve justement à ce que le filtrage puisse être cohérent. C'est aussi bien le but de l'extension (ou tout du moins ce que j'en interprète).

N'hésite pas à m'appeler @J9rem si c'est plus simple pour toi.

[J9rem]

quelle réponse complète @acheype merci avant de nous appeler, je ne comprends toujours pas à quoi correspond "je ne connais pas de site où à chaque fois qu'on sélectionne un item du filtre, tous les autres filtres se mettent à jour"

Pourrais-tu me faire une copie d'écran ? merci (ce sera plus simple ensuite pour comprendre de quoi tu parles)

[J9rem]

et merci pour ton attention @acheype je n'avais pas du tout fait attention que je mélange 2 notions. le comportement intrafiltersmode (OR et AND) et le comportement interfiltersmode.

Effectivement, je me suis bien trompé, le mode sublevel ne concerne que la partie interfiltersmode. Je vais réfléchir ces prochains jours à une implémentation qui permet de conserver le mode OR en intrafiltersmode car effectivement, c'est un comportement habituel sur d'autres sites aussi (et c'est le comportement par défaut de yeswiki en plus)

Concernant l'activation de ce sublevel, je vais réfléchir à une activation automatique qui évite de charger les choses si ça n'est pas nécessaire. Et effectivement, tu as bien raison, ce serait bien pratique pour l'usager que ça s'active tout seul.

En tout cas merci pour tes tests pointus, ça permet de ne pas attendre que d'autres usagers et usagères moins habituées à YesWiki nous fassent remonter ces soucis dans plusieurs mois quand je serai sur une autre fonctionnalité.

Et à mon avis, ce qui concerne la mise à jour des filtres des autres facettes, je pense que c'est le fait que dans ce que je propose, les filtres soient masqués si aucune fiche ne correspond. On pourrait plutôt avoir (0) + case à cocher désactivée, non ? au lieu de masquer le champ ?

[acheype]

nos réponses se croisent, voici mon message qui répond à ton premier :

je t'en prie, j'ai pris le temps car ce module a pour moi un très beau potentiel et répond vraiment à un besoin qu'on a depuis longtemps dans la communauté. Et techniquement c'est un gros travail, donc autant qu'il soit pleinement valorisé. Il manque à mon avis juste un peu de clarté fonctionnelle pour qu'il puisse être facilement utilisé.

Pour répondre à ta question, je te remets l'exemple que je donnais plus haut avec un peu plus de texte : ici pas de soucis, quand je sélectionne un item de la liste parente, la liste liée se met bien à jour. C'est bien le but du module et pour cela, ça me semble normal qu'il y ait un affichage dynamique.

là maintenant, c'est problématique que quand on ait "Economie / Emploi (1)" qui disparaisse dans la liste parente. Car il peut vouloir afficher aussi les fiches qui ont "Economie / Emploi". Et en plus, ce ne me semble pas le comportement attendu vu qu'on entre 2 facettes différentes et que c'est le OU qui est utilisé à la fois de base YesWiki et normalement aussi dans ton extension car intrafiltermode concerne uniquement les valeurs sélectionnées au sein de la même facette. et de la même façon, on a "Culture" qui passe de "(27)" à "2"... je faisais la comparaison avec d'autres sites car normalement on n'a pas d'affichage dynamique en fonction de ce qui a été sélectionné, ça permet à l'utilisateur de bien comprendre combien de fiche correspondent à chaque item et si ça fait que changer c'est le bordel dans sa tête (dans la mienne en tout cas :rofl:)

[acheype]

pour le deuxième message :

avec plaisir :) on est raccord du coup sur l’activation par défaut de sublevel et de garder par défaut intrafiltermode à OR, super ! j'ai essayé de bien y réfléchir et j'ai du mal à imaginer des cas pour intrafiltermode avec AND, mais pourquoi pas, c'est juste que vu l'habitude qu'il y a sur le web, ça risque de ne pas être clair pour l'utilisateur. Mais vu que c'est codé et optionnel, pourquoi pas le garder :)

et concernant les filtres des autres facettes, comme expliqué dans mon dernier message, même si on ne coche pas l'option pour ne pas afficher les options avec (0), ça me semble toujours problématique.

[J9rem]

et concernant les filtres des autres facettes, comme expliqué dans mon dernier message, même si on ne coche pas l'option pour ne pas afficher les options avec (0), ça me semble toujours problématique.

je vais refaire une passe sur ce point, car il y a sûrement un "trou dans la raquette"

[J9rem]

@acheype je viens de pousser la version 1.3.3, peux-tu me dire si, maintenant, le comportement OU en intrafilter correspond à ce que tu attendais ?

Pour la mise à jour des catégories de niveaux 1 qui disparaissent en fonction des catégories de niveaux 2, ....je cherche encore la solution.

[J9rem]

Avec la version 1.3.4, je pense avoir trouvé quelque chose pour que la catégorie mère ne perde pas ses filtres en fonction de ce qu'on a coché dans la catégorie fille.

Toutefois, le comportement de YesWiki entre les facettes reste un AND, je n'ai pas trop envie de m'aventurer dans la modification de ce point pour le moment le temps de vérifier si déjà ça fonctionne mieux.

[acheype]

Merci @J9rem pour ces mises à jour. C'est top que maintenant les liens entre champs de niveau 1 et de niveau 2 soient toujours pris en compte. Ca m'a permis de mettre le mode intrafiltermode à OR qui est plus intuitif pour l'utilisateur :+1:

Pour l'autre point, j'ai l'impression qu'on ne s'est pas bien compris.

Déjà par rapport à :

Toutefois, le comportement de YesWiki entre les facettes reste un AND, je n'ai pas trop envie de m'aventurer dans la modification de ce point pour le moment le temps de vérifier si déjà ça fonctionne mieux.

Ca me paraît complètement logique qu'entre facette, il y ait un comportement AND. Les modifications que je proposais était pour que ce module soit à mon sens plus intuitif en suivant les comportements classiques qu'on voit sur le web. Ainsi, je ne remet pas en cause ce AND entre paramètre coché de différentes facettes.

Avec la version 1.3.4, je pense avoir trouvé quelque chose pour que la catégorie mère ne perde pas ses filtres en fonction de ce qu'on a coché dans la catégorie fille.

C'est plus à ce niveau qu'on s'est mal compris. Pour moi, pour revenir à ce qu'on voit ailleurs, il faudrait faire aucune mise à jour des options de toutes les facettes quand on en sélectionne une. C'est d'ailleurs le comportement de YesWiki à la base.

• Pour moi, c'est indépendant du lien champ niveau 1 / champ niveau 2, donc pas lié au parent.
• Là j'ai bien les champs de mon champ parent qui continue d'être affiché (donc c'est mieux) mais le nombre à côté change.

C'est ce que j'entendais quand je disais :

je faisais la comparaison avec d'autres sites car normalement on n'a pas d'affichage dynamique en fonction de ce qui a été sélectionné, ça permet à l'utilisateur de bien comprendre combien de fiche correspondent à chaque item et si ça fait que changer c'est le bordel dans sa tête (dans la mienne en tout cas 🤣)

Peut-être as-tu des utilisateurs qui veulent qu'à chaque sélection toutes les facettes se mettent à jour avec les liées et je comprendrais du coup que tu l'ais codé comme cela. Mais pour moi, c'est un comportement qu'on ne voit pas ailleurs, donc il serait plus approprié de le mettre en option vu que ce n'est pas ce qu'on voit dans les sites en général.

Merci en tout cas pour les mises à jour que tu as faites.

[J9rem]

@acheype je pense qu'on peut clore cette Issue car elle correspond à des remarques sur un état de twolevels qui a été modifié depuis et qui a répondu en partie à la problématique. Si un comportement attendu subsiste encore avec la dernière version, je propose une nouvelle issue dédiée pour éviter de mélanger les différents types d'amélioration requises (mais les remarques de cette issue restent pertinentes)

[acheype]

Ok ça me va comme cela. Le dernier truc important c'était de mettre intrafiltermode à or par défaut.