Recherche avancée : champ complémentaire string

[johanricher]

Dépend de :

• Améliorer le moteur de recherche #593

Description

Contexte, User Story, parcours, maquette... voir epic :

• Recherche avancée #290

Le périmètre de ce ticket concerne l'implémentation dans le menu "Affiner la recherche" d'un seul type de champ complémentaire : string (sans enum).

L'implémentation pourrait (ce n'est pas un must have) être réalisée en même temps que :

• Recherche avancée : Plusieurs valeurs par filtre #591

Critère d'acceptation

• Quand un catalogue est créé avec un schéma spécifique, si celui-ci contient un ou plusieurs champs complémentaires string (sans enum), ils doivent apparaitre automatiquement (sans intervention particulière de notre part) dans le menu "Affiner la recherche", uniquement si il y a une valeur sélectionnée dans le filtre "Catalogue".
• Dans l'UI de recherche, l'implémentation permet de filtrer chaque champ de type string avec une valeur de texte libre. Le résultat de la recherche sera la liste de toutes les fiches qui contiennent, dans le champ filtré, la valeur de texte.
  • Cela diffère de l'implémentation actuelle pour les champs de type string du schéma commun (voir par exemple champs mots_cles et service), où l'utilisateur doit choisir une valeur parmi celles en base et ne peut pas en saisir une librement.

[Volubyl]

@johanricher petites questions/demande de clarification.

Imaginons le jeu de donnée "Restaurants, brasseries et cafétérias des CROUS" appartenant au catalogue du Ministère de la culture

Ce catalogue possède un champs complémentaire "Référentiel ou norme" de type texte.

En remplissant ce jeu de donnée, un utilisateur peut donc écrire une chaine de caractère comme valeur pour ce champs.

Imaginons qu'un utilisateur tape "norme ISO 916000"

Sur la page recherche, l'on aura donc un filtre nommé "Référentiel ou norme".

Si je comprends ta phrase ici :

Dans l'UI de recherche l'implémentation serait la même que celle des champs de type string du schéma commun (voir par exemple champs mots_cles et service).

En cliquant sur ce filtre, l'utilisateur vera une liste des valeurs possible dans laquelle il aura la possibilité de choisir "norme ISO 916000"

Si je comprends bien l'idée est que dans le filtre l'on ait toutes les valeurs qui ont été rentrée dans le formulaire pour le un champ complémentaire "Référentiel ou norme". C'est bien ça ?

Il y a un truc qui me chipotte avec cette idée et voici pourquoi :

En remplissant, le champs complémentare "Référentiel ou norme" avec la valeur "Norme ISO 916000" j'ai en fait dit que ce jeu de donnée "Restaurants, brasseries et cafétérias des CROUS" appartenant au catalogue du Ministère de la culture" spécifique avait la valeur "norme ISO 916000".

Il serait très peu probable qu'un autre jeu de donnée possède la même valeur pour un champs complémentaire donné.

Cela veut dire que si un utilisateur sélectionne la valeur "norme ISO 916000" dans le filtre, il a de très fortes chances de n'avoir toujours qu'un résultat.

De ce fait, je me demande si ce filtre est vraiment nécessaire. Tu en penses quoi ?

[johanricher]

C'est une bonne question. Dans le cas du MC ils avaient conçus globalement leurs champs complémentaires comme des champs booléens mais avec beaucoup d'exceptions. Etant donné ces exceptions, typer ces champs strictement comme des booléens ne fonctionnait pas. Par contre leur volonté de mettre des contraintes assez forte est assez compréhensible (obliger les contributeurs à choisir 1 valeur parmi 2, ou encore dans une liste dans le cas similaire du type "enum", pour éviter que ce soit le bazar).

La solution que je propose (champs complémentaires de type "string", avec côté UI un menu select + autocomplétion qui incite à saisir une valeur déjà utilisée comme "oui" ou "non", mais flexible pour permettre les exceptions) me semble un bon compromis.

Il serait très peu probable qu'un autre jeu de donnée possède la même valeur pour un champs complémentaire donné.

Dans le cas du MC, dans les champs complémentaires qui sont des champs de type "string" comme "Perspectives de diffusion" ou "Qualité des données" et d'autres, il y a énormement de valeurs qui se répètent ("Oui". "Non", "Ouvrable", "NSP"...) et qui ont vocation à être enrichies avec des informations complémentaires, notamment pour justifier et expliquer le "Oui" ou "Non".

Pour d'autres champs "string" comme "Référentiel" c'est plus varié j'ai l'impression, avec pas mal de valeurs uniques il est vrai. Mais je pense pas que ça soit gênant si les valeurs les plus courantes ("Non", "AC1"...) sont celles qui sont proposées en premier.

On verra avec d'autres organisations si ça reste vrai. :)

[johanricher]

Après analyse du sujet, on estime qu'il serait nécessaire de migrer vers un nouveau moteur de recherche (cf. #593) avant de pouvoir proposer une implémentation satisfaisante de cette fonctionnalité.