-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] Terms Filter Control #11873
[WIP] Terms Filter Control #11873
Conversation
#11375 seems to solve a similar set of use cases. Has there been any discussion about how these two PRs overlap? @tbragin @lukasolson |
@Bargs Both PRs provide similar functionality but serve different audiences. The goal of this Visualization is to provide an easy to use interface for non-technical users. The complexity of setting up the control is done by the dashboard author. The dashboard user does not need to know anything other than how to select the desired choice. This control also allows filtering across multiple indices. Each select input is tied to its own IndexPattern. Coupled with advanced setting |
@Bargs How should filter generation be implemented for selecting multiple terms? The filter is created from buildPhraseFilter imported from ui/filter_manager/lib/phrase. I was thinking multi-select could be implemented by creating a single filter that contained a What are your thoughts? |
I think this is true of the filter editor UI Lukas is working on as well. Dashboard authors can save filters to their dashboard. Dashboard users don't need to know anything other than how to edit a filter. This has the benefit of teaching them how to edit filters anywhere in Kibana, instead of just Dashboard.
All filters are associated with an index pattern. Perhaps we should make the index pattern selectable in the filter editor UI? That would enable the same workflow and make it less magical. @lukasolson? I'm particularly concerned about the overlap here because we're planning on removing the filter bar and the underlying filter model eventually. The goal is to unify everything in the query bar, so the user has one simple place to manager their query. So the filter model is shaky ground to build on at the moment. These parallel efforts are also going to end up duplicating a lot of work. For instance, your question about selecting multiple terms is something Lukas and I already discussed (I do think a bool is the way to go). Worse than just duplicating work, we might solve the same problem in different ways leading to an inconsistent user experience. Will multi-term queries be handled the same way? Will the UI for editing date fields be the same? What about range queries? Will each field selector handle suggestions for analyzed fields in the same way? Sorry I'm sounding super negative. If I'm coming off as harsh I apologize, I don't mean to. I think the core idea (making filters easier to manager for less advanced users) is a great one! I'm just concerned we haven't thought about the overall picture with such similar features being developed in parallel, especially since we're working on a major overhaul of the query and filter bars. |
Hi all, Thanks tremendously. |
It is available in kibana 6.1 and up |
@nreese This is coming from a Kibana newbie, but are there instructions on how-to create this list in kibana visualizations? |
Under visualizations, create a |
New Control Visualization, #6884, that provides users a select dialog of terms generated by a terms agg on a field. Selecting a term creates a new match filter. Selecting a different term updates the match filter to the new value.
Fixes #11935