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

[cchaos]

Yep, already ahead of you there mate.

Mocks are outdated, please check those in the original issue description

Essentially we need to utilize a larger area for these more complicated UI's.

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

[cchaos]

I suppose we could entertain the idea of each item having it's own KQL input. However, what we run into is the inability to see the entire search query per line. What's not obvious in my mocks is that if the query is really long, the area that shows it would wrap the query to multiple lines allowing the whole thing to be visible.

Example:

[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