Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recherche avancée : champ complémentaire string #564

Open
johanricher opened this issue Feb 7, 2023 · 3 comments
Open

Recherche avancée : champ complémentaire string #564

johanricher opened this issue Feb 7, 2023 · 3 comments
Labels
hold Cette PR est bloquée par un autre problème

Comments

@johanricher
Copy link
Member

johanricher commented Feb 7, 2023

Dépend de :

Description

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

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 :

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.
@johanricher johanricher added this to Backlog in Outil de catalogage de données via automation Feb 7, 2023
@johanricher johanricher moved this from Backlog to Prêt à développer in Outil de catalogage de données Feb 7, 2023
@Volubyl
Copy link
Collaborator

Volubyl commented Feb 14, 2023

@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 ?

@Volubyl Volubyl moved this from Prêt à développer to Exploration en cours in Outil de catalogage de données Feb 14, 2023
@johanricher
Copy link
Member Author

johanricher commented Feb 14, 2023

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 johanricher moved this from Exploration en cours to Prêt à développer in Outil de catalogage de données Feb 20, 2023
@johanricher johanricher moved this from Prêt à développer to Tâches en cours in Outil de catalogage de données Feb 20, 2023
@johanricher johanricher moved this from Tâches en cours to Bloqué / En pause in Outil de catalogage de données Mar 20, 2023
@johanricher johanricher moved this from Bloqué / En pause to Tâches en cours in Outil de catalogage de données Mar 20, 2023
@johanricher johanricher changed the title Affiner la recherche : champ complémentaire string Recherche avancée : champ complémentaire string Mar 23, 2023
@johanricher
Copy link
Member Author

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é.

@johanricher johanricher moved this from Tâches en cours to Backlog in Outil de catalogage de données Mar 29, 2023
@johanricher johanricher moved this from Backlog to Exploration en cours in Outil de catalogage de données Mar 29, 2023
@Volubyl Volubyl added the hold Cette PR est bloquée par un autre problème label Mar 30, 2023
@Volubyl Volubyl moved this from Exploration en cours to Bloqué / En pause in Outil de catalogage de données Mar 30, 2023
@johanricher johanricher moved this from Bloqué / En pause to Exploration en cours in Outil de catalogage de données Apr 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hold Cette PR est bloquée par un autre problème
Projects
Development

No branches or pull requests

2 participants