Barista: Campo de filtro 2 - Levantamento de requisitos

parece ótimo caras. já tínhamos alguns requisitos em andamento sobre os quais queríamos entrar em contato com você. Eu vejo que eles já estão cobertos aqui

Pediram-nos para incluir AND, OR e NOT.
Também estados desabilitados, que você já está considerando

As primeiras simulações tinham uma seleção múltipla visualizada. Em vez de apenas obter uma lista de sugestões e selecionar uma, você obteria aquelas com caixas de seleção na frente; para que você possa selecionar vários deles. É uma versão mais simples do filtro AND e melhor do que inserir o mesmo filtro (por exemplo, país) várias vezes

Pediram-nos para incluir AND, OR e NOT.

Obrigado @subarroca por trazer isso à tona, adicionei isso à lista original de requisitos.

As primeiras simulações tinham uma seleção múltipla visualizada. Em vez de apenas obter uma lista de sugestões e selecionar uma, você obteria aquelas com caixas de seleção na frente;

Obrigado @danielkaneider por trazer isso à tona. Eu adicionei isso à lista original de requisitos.

Para alguns filtros pode haver uma grande quantidade de sugestões, por exemplo, tags. Seria bom limitá-los a N sugestões e exibir "Comece a digitar para ver mais" que seria buscado de forma assíncrona quando o usuário estiver digitando - tipo de pesquisa do lado do servidor.

Talvez valha a pena adicionar #78 aos requisitos.

Também estou contando com a implementação nº 78 no Filterfield v2. Os filtros de intervalo seriam perfeitos para casos de uso relacionados à filtragem de número de versão (por exemplo, 1.194.0).

Também estou contando com a implementação nº 78 no Filterfield v2.

Absolutamente. Já adicionei à lista. Embora eu considere que muitos deles são realmente construídos como uma extensão (ou seja, não fornecidos pela própria biblioteca barista), é bom ter todos esses casos de uso para extensões presentes também, para definirmos a interface entre o filtro- campo v2 e uma extensão personalizada melhor.

Temos exatamente o caso de uso que @Argeath descreveu, com muitas tags para filtragem na visualização de novos problemas. Queremos apenas retornar um subconjunto de tags do servidor, correspondendo à consulta que o usuário inseriu no campo de filtro. E podemos até ter que limitar esses resultados correspondentes, pois pode haver muitos. Portanto, uma maneira de indicar resultados "truncados" também seria bom.

Oi, ótimo ver que você planeja dar uma repaginada no filterfield ;)

o caso de uso que temos é um pouco complexo, e não sei se as sugestões acima já o cobrem completamente. Adoraríamos poder encadear termos de filtro com conectores lógicos (AND, OR,...)

fe:
mostrar tudo para (criador=usuário E gravidade=alta) OU (criador=usuário E gravidade=baixa)

sempre nos referimos a ele como "a maneira como o jira permite filtrar problemas".
Eu já vi as "seleções múltiplas para um tipo de filtro" e as instruções AND/OR - mas será possível definir termos de filtro com colchetes (ou qualquer outra maneira) e combiná-los com operadores lógicos?

@petrabrunner Infelizmente, não acho que este seja um caso de uso para o campo de filtro em particular, pois isso se assemelha cada vez mais a um padrão de linguagem de consulta. Com certeza também existem casos de uso para o seu tipo de consulta, mas eu tentaria não misturar a funcionalidade de linguagem de consulta com o campo de filtro.
O exemplo dado por você pode parecer funcionar em um contexto de campo de filtro, mas se você se referir a _como o jira permite filtrar problemas_, isso pode ficar mais complexo muito rapidamente.
TBH, mesmo os operadores lógicos no campo de filtro provavelmente são um trecho para isso. Atualmente estou tentando descobrir o que as pessoas esperariam do campo de filtros, se tudo aqui será construído ou mesmo viável é provavelmente uma discussão para mais tarde.

Vou adicionar agrupamento lógico à lista acima, mas esteja ciente de que isso pode estar muito abaixo na lista de prioridades.

@tomheller thx pela resposta - tbh. Eu já esperava isso - pois a lógica seria bastante extensa - mas imaginei que, se eu não falar sobre nosso caso de uso, você não sabe disso;)

Também precisaríamos do recurso de carregar dados para preenchimentos automáticos como parciais. Por exemplo, carregue as primeiras 100 opções e ao procurar uma opção carregue as filtradas do servidor.

O PR para a implementação atual pode ser visto aqui: https://github.com/dynatrace-oss/barista/pull/1021

Olá a todos, também temos algumas petições, classificadas de mais a menos prioritárias:

• A capacidade de definir valores numéricos mínimo e máximo padrão para tipos de filtro de intervalo.
• Um novo tipo de filtro: o seletor de data.

Obrigado!

Seria muito legal dar suporte a formas angulares nos campos de filtro ;), então fica mais fácil de gerenciar do ponto de vista do consumidor. Talvez expor um FilterFormControl para isso ajude

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

```html
formControlName="filtro"
label="Filtrar por"
aria-label="Filtrar por controle de formulário"
clearAllLabel="Limpar tudo"

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

Oi,
Será bom ter esse recurso também:

Categoria padrão: quando o usuário começa a dar gorjeta, esta tecla é selecionada. Ao fazer isso, o usuário pode pular a etapa de selecionar a chave. Nas imagens a seguir você pode ver um exemplo disso, sendo 'Nome' a categoria padrão para filtrar:

1. Filtro não focado:
   
2. Filtro focado (o usuário clicou nele):
   
3. Gorjeta do usuário:
   
4. O usuário termina de dar gorjeta:
   
5. O usuário pressiona a tecla enter:
   

Olá, equipe! Eu tenho outra petição também, esta seria a definição:

getTagsForFilterKey(chave: string) | DtFilterFieldTag[] | Retorna um array de DtFilterFieldTag com todas as correspondências onde a chave do DtFilterFieldTag contém o parâmetro key
-- | -- | --

TL;DR: Uma nova versão da atual função getTagForFilter , para melhor atender às nossas necessidades.

Conforme discutido com Markus Heimbach, ele propôs adicionar a possibilidade de que, se você digitar inicialmente e todas as opções forem filtradas, ainda poderá enviar este texto como uma entrada de texto livre.
Em outras palavras, um texto livre além do preenchimento automático para o nível raiz.

Conforme discutido com Markus Heimbach, ele propôs adicionar a possibilidade de que, se você digitar inicialmente e todas as opções forem filtradas, ainda poderá enviar este texto como uma entrada de texto livre.
Em outras palavras, um texto livre além do preenchimento automático para o nível raiz.

Mas acho que é basicamente isso que @SaraDavilaMendez já mencionou com https://github.com/dynatrace-oss/barista/issues/951#issuecomment -686365435

Conforme discutido com Markus Heimbach, ele propôs adicionar a possibilidade de que, se você digitar inicialmente e todas as opções forem filtradas, ainda poderá enviar este texto como uma entrada de texto livre.
Em outras palavras, um texto livre além do preenchimento automático para o nível raiz.

Mas acho que é basicamente isso que @SaraDavilaMendez já mencionou com #951 (comentário)

Obrigada. Faltou este comentário.

Olá!

Recebemos alguns comentários sobre outro aspecto que poderia ser melhorado, ou seja, como o filtro lida com a entrada de texto médio/longo.

Atualmente, o widget apresenta uma "janela" de entrada de cerca de 24 a 25 caracteres, o que dificulta um pouco a revisão do texto inserido ou copiado e colado.
O widget, por exemplo, pode expandir e usar o espaço livre do lado direito, especialmente em telas grandes.

A caixa azul destaca o tamanho da caixa de entrada, o texto de exemplo é: _este é um texto moderadamente longo_

Movido para APM-266067