[Lens] Support filters aggregation

[timroes]

Lens should support the filters aggregation allowing the user to specify an individual amount of custom KQL/Lucene filters and specify custom labels for them.

[elasticmachine]

Pinging @elastic/kibana-app (Team:KibanaApp)

[timroes]

@cchaos I think we need some design input on this one. I have the feeling just cramping the same UI we use in the visualize editor into the smaller Lens popup won't really create a good UI. Especially since a user will easily add at least 3-5 filters commonly, which would create a lot of scrolling. Do you think you could provide some mockups that cover this aggregation?

• Allow specifying filters or query via KQL/Lucene (we can technically work with any of those, so I think we are also open to not have a query bar but filters, if that would end up in better design)
• Allow providing a label for each individual filter
• Allow adding/removing of filters
• Allow resorting of filters, since the order will be the same as in the chart (since ES currently can't sort filter buckets by a specific criteria), and this has been one of the more annoying limitations in visualize editor, that you can never sort those filters again.

Also there are some questions around how those dialog would be initiated. Currently the user would need to trigger that popup from the visualization configuration, since there is nothing for a filter, that you could drag from the index pattern view.

Since this is currently rather high up in the priority list, it would be nice if we could get some mockups for it.

[timroes]

Blazing fast Caroline, as always :-)

Question: would you be able to edit entries again in the dialog or you need to remove and add a new one? Since editing feels a bit weird maybe if there's only that one bar to enter the queries?

[AlonaNadler]

Keep in mind there needs to be the ability to switch the order of filter aggregation queries.
I know there are technical challenges displaying each filter under the x-axis separately.
will it help if we have one filter label under the x-axis and make the label large so we will fit details on each individual search queries?

instead of this it would say

filter(3):
version 7.x
version 8.x 
people who love apples

[wylieconlon]

@AlonaNadler @cchaos Raising this because I don't think it's been discussed yet: why are we expecting our users to type KQL queries instead of the simplified filter editor that's used in the search bar? I agree that KQL is more powerful, but I thought our target user was less interested in learning a new grammar. Even I find that the KQL docs are confusing.

The other filter editor I'm talking about is this one:

cc @flash1293 @mbondyra

[flash1293]

That's a good point, @wylieconlon - I think we should start with the KQL filter though and branch out other ways of editing.
Two reasons:

• Technical complexity: This editor is currently not exposed as an easy to consume standalone component. It would require quite some refactoring to make it usable in this place.
• Limiting the most common use case: I think the most common use case for filters is not to do a field/term match or a range, but using a query composed out of AND and ORs, often to normalize messy data (at least that's how I used it in the past).

@AlonaNadler Do you agree with the second bullet point here or is this a misconception?

[wylieconlon]

Discussed in a meeting and we have decided to go with KQL input.