Barista: Filterfield 2 - Collecte des exigences

ça a l'air super les gars. nous avions déjà quelques exigences à venir pour lesquelles nous voulions vous contacter. Je vois qu'ils sont déjà couverts ici

On nous a demandé d'inclure AND, OR et NOT.
États également désactivés, que vous envisagez déjà

Les premières simulations avaient une multi-sélection visualisée. Au lieu de simplement obtenir une liste de suggestions et d'en sélectionner une, vous obtiendriez celles avec des cases à cocher devant; vous pouvez donc en sélectionner plusieurs. C'est une version plus simple du filtre ET, et plus agréable que d'entrer plusieurs fois dans le même filtre (par exemple, le pays)

On nous a demandé d'inclure AND, OR et NOT.

Merci @subarroca d'avoir soulevé cette question, j'ai ajouté ceci à la liste originale des exigences.

Les premières simulations avaient une multi-sélection visualisée. Au lieu de simplement obtenir une liste de suggestions et d'en sélectionner une, vous obtiendriez celles avec des cases à cocher devant;

Merci @danielkaneider d'avoir soulevé cette question. J'ai ajouté ceci à la liste initiale des exigences.

Pour certains filtres, il peut y avoir une énorme quantité de suggestions, par exemple des balises. Ce serait bien de les limiter à N suggestions et d'afficher "Commencez à taper pour en voir plus" qui serait récupéré de manière asynchrone lorsque l'utilisateur tape - une sorte de recherche côté serveur.

Peut-être que ça vaudrait la peine d'ajouter #78 aux exigences.

Je compte également sur l'implémentation #78 dans Filterfield v2. Les filtres de plage seraient parfaits pour les cas d'utilisation concernant le filtrage du numéro de version (par exemple, 1.194.0).

Je compte également sur l'implémentation #78 dans Filterfield v2.

Absolument. Je l'ai ajouté à la liste. Bien que je considère que beaucoup d'entre eux sont en fait construits comme une extension (c'est-à-dire non fournis par la bibliothèque barista elle-même), il est bon d'avoir également tous ces cas d'utilisation pour les extensions présents, pour nous de définir l'interface entre le filtre- champ v2 et une extension personnalisée mieux.

Nous avons exactement le cas d'utilisation décrit par @Argeath , avec de nombreuses balises pour le filtrage dans la nouvelle vue des problèmes. Nous souhaitons uniquement renvoyer un sous-ensemble de balises du serveur, correspondant à la requête que l'utilisateur a saisie dans le champ de filtre. Et nous pourrions même devoir limiter ces résultats correspondants car il pourrait y en avoir trop. Donc, un moyen d'indiquer les résultats "tronqués" serait également bien.

Salut, super de voir que tu prévois de donner une cure de jouvence au filtre ;)

le cas d'utilisation que nous avons est un peu complexe, et je ne sais pas si les suggestions ci-dessus le couvrent déjà complètement. Nous aimerions pouvoir enchaîner les termes de filtrage avec des connecteurs logiques (ET, OU, ...)

fe :
afficher tout pour (créateur=utilisateurx ET gravité=élevé) OU (créateur=utilisateur ET gravité=faible)

nous l'appelons toujours "la façon dont jira vous permet de filtrer les problèmes".
J'ai déjà vu les "sélections multiples pour un type de filtre" et les instructions AND/OR - mais sera-t-il possible de définir des termes de filtre avec des crochets (ou de toute autre manière) et de les combiner avec des opérateurs logiques ?

@petrabrunner Malheureusement, je ne pense pas que ce soit un cas d'utilisation pour le champ de filtre en particulier, car cela ressemble de plus en plus à un modèle de langage de requête. Il existe certainement des cas d'utilisation pour votre type de requêtes, mais j'essaierais de ne pas mélanger la fonctionnalité de langage de requête avec le champ de filtre.
L'exemple que vous avez donné peut sembler fonctionner dans un contexte de champ de filtre, mais si vous vous référez à _la façon dont jira vous permet de filtrer les problèmes_, cela peut devenir plus complexe très rapidement.
TBH, même les opérateurs logiques dans le champ de filtre sont probablement exagérés. Actuellement, j'essaie de comprendre ce que les gens pourraient attendre du filtre, si tout ici sera construit ou même réalisable, c'est probablement une discussion pour plus tard.

Je vais ajouter un regroupement logique à la liste ci-dessus, mais sachez que cela pourrait être très loin dans la liste des priorités.

@tomheller merci pour la réponse - tbh. Je m'y attendais déjà - car la logique serait assez étendue - mais je me suis dit que si je ne vous parlais pas de notre cas d'utilisation, vous ne le saviez pas ;)

Nous aurions également besoin de la fonctionnalité de chargement des données pour les saisies semi-automatiques en tant que partiels. Par exemple, chargez les 100 premières options et lors de la recherche d'une option, chargez celles filtrées à partir du serveur.

Le PR pour l'implémentation actuelle peut être vu ici : https://github.com/dynatrace-oss/barista/pull/1021

Bonjour à tous, nous avons également quelques pétitions, triées du plus au moins prioritaire :

• La possibilité de définir des valeurs numériques minimales et maximales par défaut pour les types de filtres de plage.
• Un nouveau type de filtre : le sélecteur de date.

Merci!

Ce serait vraiment cool de prendre en charge les formes angulaires dans les champs de filtre ;), donc c'est plus facile à gérer du point de vue du consommateur. Peut-être que l'exposition d'un FilterFormControl pour cela aiderait

  interface FilterFormControl {
    field: string;
    value: FilterValue // any basically
    operator?: 'AND' | 'OR' | 'NOT'
    ...
  }  

```html
formControlName="filter"
label="Filtrer par"
aria-label="Filtrer par contrôle de formulaire"
clearAllLabel="Tout effacer"

```ts
// comes from a saved config
initFilters = [{
  field: 'foo',
  value: 'bar'
}];
form: FormGroup({
  filter: new FormControl(initFilters)
});

Salut,
Ce serait bien d'avoir cette fonctionnalité aussi:

Catégorie par défaut : lorsque l'utilisateur commence à donner un pourboire, cette touche est sélectionnée. Ce faisant, l'utilisateur peut ignorer l'étape consistant à sélectionner la clé. Dans les images suivantes, vous pouvez en voir un exemple, étant "Nom" la catégorie par défaut pour filtrer :

1. Filtre non ciblé :
   
2. Filtre ciblé (l'utilisateur a cliqué dessus) :
   
3. Pourboire d'utilisateur :
   
4. L'utilisateur termine le pourboire :
   
5. L'utilisateur appuie sur la touche Entrée :
   

Bonjour l'équipe! J'ai aussi une autre pétition, ce serait la définition:

getTagsForFilterKey(clé : chaîne) | DtFilterFieldTag[] | Renvoie un tableau de DtFilterFieldTag avec toutes les correspondances où la clé du DtFilterFieldTag contient le paramètre key
-- | -- | --

TL;DR : Une nouvelle version de la fonction actuelle getTagForFilter , pour mieux répondre à nos besoins.

Comme discuté avec Markus Heimbach, il a proposé d'ajouter la possibilité que si vous tapez initialement et que toutes les options sont filtrées, vous pouvez toujours soumettre ce texte en tant que saisie de texte libre.
En d'autres termes, un texte libre en plus de l'autocomplétion pour le niveau racine.

Comme discuté avec Markus Heimbach, il a proposé d'ajouter la possibilité que si vous tapez initialement et que toutes les options sont filtrées, vous pouvez toujours soumettre ce texte en tant que saisie de texte libre.
En d'autres termes, un texte libre en plus de l'autocomplétion pour le niveau racine.

Mais je pense que c'est essentiellement ce que @SaraDavilaMendez a déjà mentionné avec https://github.com/dynatrace-oss/barista/issues/951#issuecomment -686365435

Comme discuté avec Markus Heimbach, il a proposé d'ajouter la possibilité que si vous tapez initialement et que toutes les options sont filtrées, vous pouvez toujours soumettre ce texte en tant que saisie de texte libre.
En d'autres termes, un texte libre en plus de l'autocomplétion pour le niveau racine.

Mais je pense que c'est essentiellement ce que @SaraDavilaMendez a déjà mentionné avec # 951 (commentaire)

Merci. J'ai raté ce commentaire.

Salut!

Nous avons reçu des commentaires sur un autre aspect qui pourrait être amélioré, à savoir la façon dont le filtre traite la saisie de texte moyen/long.

Actuellement, le widget présente une "fenêtre" de saisie d'environ 24-25 caractères qui rend un peu difficile la révision du texte que l'on saisit ou copie-colle.
Le widget, par exemple, pourrait se développer et utiliser l'espace libre sur son côté droit, en particulier sur les grands écrans.

La case bleue met en évidence la taille de la zone de saisie, l'exemple de texte est : _ceci est un texte modérément long_

Déplacé vers APM-266067