[Discover][ES|QL] Filtering by clicking should keep the selected chart type #184631
Assignees
Labels
enhancement
New value added to drive a business result
Feature:Discover
Discover Application
Feature:ES|QL
ES|QL related features in Kibana
impact:medium
Addressing this issue will have a medium level of impact on the quality/strength of our product.
Team:DataDiscovery
Discover, search (e.g. data plugin and KQL), data views, saved searches. For ES|QL, use Team:ES|QL.
Team:ESQL
ES|QL related features in Kibana
Comments
stratoula
added
Feature:Discover
|
Pinging @elastic/kibana-data-discovery (Team:DataDiscovery) |
|
Pinging @elastic/kibana-esql (Team:ESQL) |
stratoula
added
enhancement
|
@jughosta not sure how easy it will be to accomplish that but it would be very cool 😍 |
|
The chart style gets reset when query changes. It's the case here too as "where" clause gets added. Need to think what kind of special handling we could add for the check on query change. |
2 tasks
|
I was thinking about it. Maybe we should check if the chart used columns (fields) exist in the updates query. In case they do, we should not change the chart type. The suggestions api has the preferredChartType property that we can possibly use. |
2 tasks
2 tasks
stratoula
added a commit
that referenced
this issue
Nov 5, 2024
…ble (#197453) ## Summary Closes #184631 It keeps the chart configuration when the user is doing actions compatible with the current query such as: - Adding a where filter (by clicking the table, the sidebar, the chart) - Changes the breakdown field and the field type is compatible with the current chart - Changing to a compatible chart type (from example from bar to line or pie to treemap) - Changing the query that doesnt affect the generated columns mapped to a chart. For example adding a limit or creating a runtime field etc. The logic depends on the suggestions. If the suggestions return the preferred chart type, then we are going to use this. So it really depends on the api and the type / number of columns. It is as smarter as it can in order to not create bugs. I am quite happy with the result. It is much better than what we have so far.  ### Next steps I would love to do the same on the dahsboard too, needs more time though. But the changes made here will def work in favor ### Checklist - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [x] [Flaky Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was used on any tests changed --------- Co-authored-by: Marta Bondyra <4283304+mbondyra@users.noreply.github.com>
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this issue
Nov 5, 2024
…ble (elastic#197453) ## Summary Closes elastic#184631 It keeps the chart configuration when the user is doing actions compatible with the current query such as: - Adding a where filter (by clicking the table, the sidebar, the chart) - Changes the breakdown field and the field type is compatible with the current chart - Changing to a compatible chart type (from example from bar to line or pie to treemap) - Changing the query that doesnt affect the generated columns mapped to a chart. For example adding a limit or creating a runtime field etc. The logic depends on the suggestions. If the suggestions return the preferred chart type, then we are going to use this. So it really depends on the api and the type / number of columns. It is as smarter as it can in order to not create bugs. I am quite happy with the result. It is much better than what we have so far.  ### Next steps I would love to do the same on the dahsboard too, needs more time though. But the changes made here will def work in favor ### Checklist - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [x] [Flaky Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was used on any tests changed --------- Co-authored-by: Marta Bondyra <4283304+mbondyra@users.noreply.github.com> (cherry picked from commit ccbcab9)
mgadewoll
pushed a commit
to mgadewoll/kibana
that referenced
this issue
Nov 7, 2024
…ble (elastic#197453) ## Summary Closes elastic#184631 It keeps the chart configuration when the user is doing actions compatible with the current query such as: - Adding a where filter (by clicking the table, the sidebar, the chart) - Changes the breakdown field and the field type is compatible with the current chart - Changing to a compatible chart type (from example from bar to line or pie to treemap) - Changing the query that doesnt affect the generated columns mapped to a chart. For example adding a limit or creating a runtime field etc. The logic depends on the suggestions. If the suggestions return the preferred chart type, then we are going to use this. So it really depends on the api and the type / number of columns. It is as smarter as it can in order to not create bugs. I am quite happy with the result. It is much better than what we have so far.  ### Next steps I would love to do the same on the dahsboard too, needs more time though. But the changes made here will def work in favor ### Checklist - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [x] [Flaky Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was used on any tests changed --------- Co-authored-by: Marta Bondyra <4283304+mbondyra@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the feature:
Recently we added the support of creation of where filters when we are clicking on a:
This is very cool but if the user has selected a different chart type (for example a tagcloud) and then clicks to add a filter then the user's selection chart type is being lost and the default one is being rendered (which is usually an XY chart). This happens also in a saved search.
Ideally we dont want filtering to change our chart configuration.
The text was updated successfully, but these errors were encountered: