You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Comportement inattendu du filtre de la liste déroulante #502
A première vue, le comportement de la liste déroulante avec filtre semble montrer des comportements inattendus lors de certaines saisies. Pour illustrer mon propos, je vais utiliser un cas où on permet à un utilisateur de sélectionner un employeur.
Un premier exemple montre qu'un filtre scolaire rivet ramène des entrées qui ne contiennent aucun des deux termes:
Est-ce que les entrées ramenées l'ont été du fait de la présence d'un mot se rapprochant des termes (rive -> rivet, salaire -> scolaire)?
Autre exemple:
Ici, on voit que le terme Saguenay ne suffit pas à ramener l'élément "Centre de services scolaire des Rives-du-Saguenay" alors qu'il fait bel et bien partie de la liste.
Bref, nous aimerions savoir si le filtre actuel réagit comme vous l'avez prévu. Si c'est le cas, nous aimerions connaître les règles qui dictent son comportement et voir s'il est possible de le modifier à partir de la définition de nos formulaires. Nos configurations actuelles ressemblent à ceci:
- type: listeDeroulante
name: textEmploi
label:
fr: Sélectionnez le nom de l'employeur
en: Select the name of the employer
[...]
additionals:
recherchable: true
trier-options-par-libelle: true
J'ai fait des recherches dans la documentation mais je n'ai pas trouvé d'explications à propos du paramétrage du membre additionals (peut-être que je n'ai pas regardé au bon endroit).
Est-ce que les entrées ramenées l'ont été du fait de la présence d'un mot se rapprochant des termes (rive -> rivet, salaire -> scolaire)?
La réponse est OUI, par défaut les listes déroulantes ont le paramètre recherche-floue: true, ce qui veut dire que les termes se rapprochant du terme recherché sortent dans les résultats. Ça permet de donner des résultats en cas de faute de frappe.
Si vous voulez une recherche stricte, sur votre champ listeDeroulante il faut mettre recherche-floue: false dans la config.
Pour votre seconde question
Ici, on voit que le terme Saguenay ne suffit pas à ramener l'élément "Centre de services scolaire des Rives-du-Saguenay" alors qu'il fait bel et bien partie de la liste.
Le fonctionnement de la recherche actuel est le suivant :
Chaque option de liste est analysée et chaque mot est indexé pour la recherche. Votre problème vient du fait que pour déterminer les "mots" à indexer le séparateur par défaut qui est utilisé est l'espace.
Dans votre cas, Saguenay est à la fin du mot et séparé avec des tirets. Ce que l'engin indexe pour cette option :
"Centre", "de", "services", "scolaire", "des", "Rives-du-Saguenay"
La recherche s'exécute et retourne les résultats QUI DÉBUTENT par le terme saisi... Dans votre cas précis "Saguenay" ne sortira pas.
Solution actuelle
Spécifier un autre séparateur de mots au niveau de la config du champ.
Il existe un paramètre non documenté regex-separateur-recherche qui vous permettrait d'utiliser les espaces et les tirets comme séparateur de mots.
Par contre après vérification je constate que le paramètre en question n'est actuellement pas pris en charge. Il faudrait que nous fassions un petit correctif pour l'activer.
Autre solution possible
Modifier l'engin de recherche ou ajouter un nouveau paramètre afin de permettre une recherche "partielle" qui cherche n'importe où dans les mots indexés.
Questions pour vous
À quel point le problème vous affecte en ce moment? Est-ce un bloquant pour la mise en production d'un formulaire?
En réponse à votre question, NON, le problème n'est pas un bloquant pour la mise en production d'un formulaire. Par contre, nous constatons que pour un de nos formulaires actuels, nous avons un volume important de saisies manuelles d'un nom d'employeur pourtant disponible dans une liste déroulante, ce qui occasionne des traitements supplémentaires à nos agents. Notre hypothèse est que, dans bien des cas, le filtre de recherche ne montre pas le comportement attendu par nos usagers.
Nous avons pensé à tester de nouvelles configurations du filtre pour voir si on pourrait obtenir un comportement qui correspond davantage à ce que nos usagers s'attendent à avoir. Je pense que l'utilisation de regex-separateur-recherche nous permettrait de faire un bon bout. Sinon, à part recherche-floue, y a-t-il d'autres paramètres avec lesquels nous pouvons jouer?
Concernant le formulaire pour lequel vos utilisateurs ont actuellement des problèmes (saisie manuelle alors que le choix est dans la liste), est-ce l'exemple que vous nous avez donné dans l'issue? Est-ce un autre problème?
Ce serait intéressant d'avoir cet exemple afin de décider de la solution à mettre en place.
Est-ce que si la recherche était complètement partielle (donc le texte recherché est trouvé n'importe où dans le terme et pas seulement au début d'un mot) règlerait vos problèmes?
Alors oui, l'exemple fourni ci-haut est bel et bien celui pour lequel nous avons un "problème". Je constate cependant que nous avons eu 293 cas de saisie manuelle sur plus de 7900 formulaires reçus. Sur ces 293 cas, il y en a sûrement beaucoup pour lesquels la saisie manuelle était inévitable (ex. employeur absent de la liste). Donc même en modifiant le comportement du filtre nous ne réussirons probablement pas à abaisser le nombre de traitements manuels de manière significative. Je vais valider le tout avec le demandeur et je vous reviens. Mais d'après moi, si on peut faire fonctionner correctement regex-separateur-recherche (pour indexer les termes d'un mot qui comporte un ou plusieurs trait d'union) ça permettrait de résoudre la plupart des cas où l'usager aurait dû trouver l'élément recherché.
Comme le problème décrit n'apparait pas comme étant majeur, nous ne pouvons accorder un niveau de priorité très élevé à sa résolution. Ceci étant dit, nous serons heureux de pouvoir améliorer la fonctionnalité du filtre à l'aide de la propriété regex-separateur-recherche lorsque celle-ci sera rendue disponible (Dany m'a indiqué que ça pourrait se faire lors du passage à Vue 3). Cela nous permettra sans doute de diminuer quelque peu le nombre de cas à traiter manuellement, ce qui sera très apprécié par nos agents.
Sa recommandation est parfaite en ce qui a trait au passage à Vue 3.
Si c'est bon pour vous c'est parfait je vais faire le correctif afin de rendre la propriété regex-separateur-recherche disponible dans notre version vue3 et peut-être même ajouter une option pour que la recherche ne se limite pas au début des mots ce qui serait encore plus simple dans votre cas je crois.
Activity
j0ber commentedon Oct 23, 2026
Bonjour,
Désolé pour le délai de la réponse...
Pour votre première question
Est-ce que les entrées ramenées l'ont été du fait de la présence d'un mot se rapprochant des termes (rive -> rivet, salaire -> scolaire)?
La réponse est OUI, par défaut les listes déroulantes ont le paramètre
recherche-floue: true, ce qui veut dire que les termes se rapprochant du terme recherché sortent dans les résultats. Ça permet de donner des résultats en cas de faute de frappe.Si vous voulez une recherche stricte, sur votre champ listeDeroulante il faut mettre
recherche-floue: falsedans la config.Pour votre seconde question
Ici, on voit que le terme Saguenay ne suffit pas à ramener l'élément "Centre de services scolaire des Rives-du-Saguenay" alors qu'il fait bel et bien partie de la liste.
Le fonctionnement de la recherche actuel est le suivant :
Chaque option de liste est analysée et chaque mot est indexé pour la recherche. Votre problème vient du fait que pour déterminer les "mots" à indexer le séparateur par défaut qui est utilisé est l'espace.
Dans votre cas, Saguenay est à la fin du mot et séparé avec des tirets. Ce que l'engin indexe pour cette option :
"Centre", "de", "services", "scolaire", "des", "Rives-du-Saguenay"
La recherche s'exécute et retourne les résultats QUI DÉBUTENT par le terme saisi... Dans votre cas précis "Saguenay" ne sortira pas.
Solution actuelle
Spécifier un autre séparateur de mots au niveau de la config du champ.
Il existe un paramètre non documenté
regex-separateur-recherchequi vous permettrait d'utiliser les espaces et les tirets comme séparateur de mots.Par contre après vérification je constate que le paramètre en question n'est actuellement pas pris en charge. Il faudrait que nous fassions un petit correctif pour l'activer.
Autre solution possible
Modifier l'engin de recherche ou ajouter un nouveau paramètre afin de permettre une recherche "partielle" qui cherche n'importe où dans les mots indexés.
Questions pour vous
À quel point le problème vous affecte en ce moment? Est-ce un bloquant pour la mise en production d'un formulaire?
sbeaulieu-rrq commentedon Oct 26, 2026
Merci beaucoup pour le retour.
En réponse à votre question, NON, le problème n'est pas un bloquant pour la mise en production d'un formulaire. Par contre, nous constatons que pour un de nos formulaires actuels, nous avons un volume important de saisies manuelles d'un nom d'employeur pourtant disponible dans une liste déroulante, ce qui occasionne des traitements supplémentaires à nos agents. Notre hypothèse est que, dans bien des cas, le filtre de recherche ne montre pas le comportement attendu par nos usagers.
Nous avons pensé à tester de nouvelles configurations du filtre pour voir si on pourrait obtenir un comportement qui correspond davantage à ce que nos usagers s'attendent à avoir. Je pense que l'utilisation de
regex-separateur-recherchenous permettrait de faire un bon bout. Sinon, à partrecherche-floue, y a-t-il d'autres paramètres avec lesquels nous pouvons jouer?j0ber commentedon Oct 26, 2026
Bonjour,
Actuellement il n'y a pas vraiment d'autres paramètres intéressants pour vous : https://formulaires.it.mtess.gouv.qc.ca/fr/Form/7/P700U/0/N/#p=listesDeroulantes
Concernant le formulaire pour lequel vos utilisateurs ont actuellement des problèmes (saisie manuelle alors que le choix est dans la liste), est-ce l'exemple que vous nous avez donné dans l'issue? Est-ce un autre problème?
Ce serait intéressant d'avoir cet exemple afin de décider de la solution à mettre en place.
Est-ce que si la recherche était complètement partielle (donc le texte recherché est trouvé n'importe où dans le terme et pas seulement au début d'un mot) règlerait vos problèmes?
sbeaulieu-rrq commentedon Oct 27, 2026
Bonjour,
Alors oui, l'exemple fourni ci-haut est bel et bien celui pour lequel nous avons un "problème". Je constate cependant que nous avons eu 293 cas de saisie manuelle sur plus de 7900 formulaires reçus. Sur ces 293 cas, il y en a sûrement beaucoup pour lesquels la saisie manuelle était inévitable (ex. employeur absent de la liste). Donc même en modifiant le comportement du filtre nous ne réussirons probablement pas à abaisser le nombre de traitements manuels de manière significative. Je vais valider le tout avec le demandeur et je vous reviens. Mais d'après moi, si on peut faire fonctionner correctement
regex-separateur-recherche(pour indexer les termes d'un mot qui comporte un ou plusieurs trait d'union) ça permettrait de résoudre la plupart des cas où l'usager aurait dû trouver l'élément recherché.sbeaulieu-rrq commentedon Oct 30, 2026
Comme le problème décrit n'apparait pas comme étant majeur, nous ne pouvons accorder un niveau de priorité très élevé à sa résolution. Ceci étant dit, nous serons heureux de pouvoir améliorer la fonctionnalité du filtre à l'aide de la propriété
regex-separateur-recherchelorsque celle-ci sera rendue disponible (Dany m'a indiqué que ça pourrait se faire lors du passage àVue 3). Cela nous permettra sans doute de diminuer quelque peu le nombre de cas à traiter manuellement, ce qui sera très apprécié par nos agents.j0ber commentedon Oct 30, 2026
Dany? :) lol
Sa recommandation est parfaite en ce qui a trait au passage à Vue 3.
Si c'est bon pour vous c'est parfait je vais faire le correctif afin de rendre la propriété
regex-separateur-recherchedisponible dans notre version vue3 et peut-être même ajouter une option pour que la recherche ne se limite pas au début des mots ce qui serait encore plus simple dans votre cas je crois.