Closed Gaetanbrl closed 3 years ago
A ajouter dans ce besoin, qu'un message devrait apparaitre en invitant l'utilisateur à affiner la recherche dès que le nombre de réponse est inférieur au nombre d'éléments indiqués dans le résultat.
Les deux API emprises OA et PA sont à faire modifier.
@dcottenc demande validation pour ce comportement non décrit précisément :
1. Par défaut, si l'API retourne un nombre de résultats inférieur au nombre de résultats attendues ==> on informe l'utilisateur qu'une saisie est requise et on ne charge rien dans la liste (liste vide si on clique sur la flèche, le message pouvant être "veuillez saisir un nom" à l'ouverture de la liste vide ).
Test réalisé (reprise du component cadastrapp)
2. Si l'API retourne un nombre de résultats < ou = au nombre annoncé (champ totalElements
) alors on affiche toute la liste comme c'est le cas actuellement
A ajouter dans ce besoin, qu'un message devrait apparaitre en invitant l'utilisateur à affiner la recherche dès que le nombre de réponse est inférieur au nombre d'éléments indiqués dans le résultat.
Je propose d'ajouter pour chaque filtre un text comme pour les dates. A côté du texte, lorsqu'une autocomplétion par début de saisie est attendue, on affichera un icône avec un message qui s'affiche au survol de la souris.
Est-ce que cela convient @dcottenc ?
je complète @dcottenc après réflexion :
Il serait préférable de savoir à l'avance lesquels dépassent... je ne vois pas comment faire pour savoir à l'avance lesquels nécessitent une autocomplétions et lesquels non à moins de faire des appels en série pour examiner les retours (peu performant et pas du tout optimal) afin de savoir quel composant choisir.
Est-ce que cela convient @dcottenc ?
A confirmer demain avec la MOA
Il serait préférable de savoir à l'avance lesquels dépassent...
Je ne suis pas certain de bien saisir la question. Mais s'il s'agit de faire une liste fixe des champs avec liste déroulante avec ce traitement, je peux voir ca avec la MOA
Je ne suis pas certain de bien saisir la question. Mais s'il s'agit de faire une liste fixe des champs avec liste déroulante avec ce traitement, je peux voir ca avec la MOA
Au chargement des combobox, soit on affiche une liste entière, soit on affiche rien et l'utilisateur doit saisir des caractère pour démarrer une recherche sur autocomplétions.
Actuellement, le seul moyen de faire la différence c'est d'appeler l'API et de comparer le nombre de résultats attendus / le nombre de résultats retournés dans le corps de la réponse.
On doit donc faire 1 appel test pour tous les champs. Je préfèrerai que l'on fixe d'avance les champs avec saisie obligatoire (Par exemple dans cadastrapp, les valeurs étant larges on a par défaut toutes les listes en saisie obligatoire, il n'y a pas d'appel préliminaire).
Je préfèrerai que l'on fixe d'avance les champs avec saisie obligatoire
Je pense également que cette liste de champs doit être fixe. Contrairement à CadastrApp, nous avons besoin de champs avec des listes déroulantes pre chargés car peu de valeurs (ex : Etape)
Je pense également que cette liste de champs doit être fixe
Parfait ! En attente d'une liste avec la MOA donc.
@dcottenc les PLUI sont du moins déjà testables sur le contexte de VA
@Gaetanbrl la liste PLUi est toujours vide même quand je commence à saisir (sous Firefox) Dans l'exemple suivant, il y a normalement 19 zonages seulement
Le nombre de caractère est à minima de 3 en général avant de lancer la recherche, quels sont les attentes pour ce comportement ? A partir de un caractère ?
Le nombre de caractère est à minima de 3 en général
Oui effectivement mais dans le cas du PLUi, dès le premier caractère c'est discriminant et surtout il y a des zones nommées avec 1 ou 2 caractères qu'il faut pouvoir sélectionner
@dcottenc à prévoir avec la liste des champs :
En cours :
@dcottenc visible sur context VA
Rajouté par @dcottenc le 17/08/21.
@dcottenc j'ai placé dans l'issue 80 cette fonction d'autocomplétions. SI le reste est valide on peut fermer celle-ci.
Lors des tests, j'ai des comportements bizarres et différents selon les cas.
[x] Pour Filtre/PLUi, si on saisit quelques caractères puis on clique sur la croix alors on ne voit plus les caractères que l'on saisit (des fois la croix disparait)
[x] Pour Ajout/emprise opération, si on sélectionne Nature = En diffus, puis on saisit des caractères qui ne retournent pas de valeur alors le clic sur la croix n'efface pas ces caractères (idem pour Ajout/emprise programme)
Correctifs Testable sur le contexte VA @dcottenc
Encore deux choses (valable pour tous les champs) :
En attendu, on aurait plutôt une liste vide.
C'est le comportement des combo dans cadastrapp. Jusque là ce ne me choque pas. Ca permet même de garder une liste chargée (un peu comme un historique de la dernière valeur recherchée).
En attendu, ne devrait-elle pas être supprimée ? Il y a un risque d'erreur à l'enregistrement.
Idem, comportement par défaut. Je peux rajouter une évolution sur cette combo pour forcer la sélection. Car dans certains cas, on peut vouloir saisir / coller la valeur comme pour un champ date.
Encore deux choses (valable pour tous les champs) : Si on utilise des caractères qui retournent des valeurs dans la liste, puis on clique sur la croix, alors si on clique sur la liste déroulante on retrouve les valeurs précédentes. En attendu, on aurait plutôt une liste vide. Si on utilise des caractères qui ne retournent une liste vide, puis on clique ailleurs (perte focus), alors la valeur erronée reste affichée. En attendu, ne devrait-elle pas être supprimée ? Il y a un risque d'erreur à l'enregistrement.
Après vérification, le comportement est identique dans Cadastrapp.
Corrections testées et validées.
Description
Suite à la livraison 1.1.4 il est vérifié que le total de résultats peut être supérieur au nombre de résultats retournés par l'API (max 100).
Même si la limite est modifié (ex: max 200) il n'est pas garantit que les valeurs retournées par l'API ne dépasse pas cette nouvelle limite.
En utilisant l'autocomplétion du composant par défaut (ce qui a été convenu initialement pour la v1), la liste n'est pas rechargée à la saisie et il n'est pas possible de retourner un nombre de résultat inférieur car la liste se charge une seule fois à l'initialisation. Lors d'une saisie, le composant recherche dans les valeurs chargées à l'initialisation et non via des appels API.
Pour être certain que l'utilisateur trouve ce qu'il recherche, l'API doit être utilisée pour l'autocomplétion sans utiliser l'autocomplétion de base du composant.
Les éléments concernés dans un premier temps sont :
tabou2/plui?libelle=1AU*&asc=true
tabou2/operations/emprises?natureId=3&estSecteur=false&nom=via*&asc=true
tabou2/programmes/emprises?nom=1-*&asc=true
=> API KO actuellementAPI https://portail-test.sig.rennesmetropole.fr/tabou2/operations?nom=Les*&estSecteur=false&asc=true
Remarque : critère estSecteur=false obligatoireAPI https://portail-test.sig.rennesmetropole.fr/tabou2/operations?nom=Les*&estSecteur=false&asc=true
Remarque : critère estSecteur=false obligatoire