-
Notifications
You must be signed in to change notification settings - Fork 14.4k
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
[SIP-49] Dashboard Filter Component #10285
Comments
Issue-Label Bot is automatically applying the label Links: app homepage, dashboard and code for this bot. |
I love this proposal! 😍 |
How about not in / exclude filter ? |
Good point! I added in the request list. |
If I understand this SIP correctly it is all about making a component which is responsible both Visually and logically to consolidate the set of filters that will be applied to all of the existing charts(slices) when fetching the data so the component responsibilities are :
is this correct? Additionally there can be multiple filter components : global and one for each tab |
@graceguo-supercat One of the things I just bumped into today is wanting the ability to not load charts until the dashboard filter has been applied by the user. |
@graceguo-supercat I wanted to provide additional feedback to this SIP & to the community to understand our frustration as a user of Superset with the disconnect between charts and the filters. One of the major issues that we struggle with is we define our generic charts with nearly no filters and then apply the filters only from the dashboard perspective to allow all our charts to interactively be changed through the dashboard filter. When we're making the individual charts the problem is the filter box is not tied into that chart yet. This means the individual charts when crafting them are running queries that basically are along the lines of, "fetch all data". For us, that is not doable because it is billions upon billions and PB kind of storage. Once on the dashboard, the same issue happens when the filter box hasn't had values selected by the user yet but the charts try to run with the "defaults" on the filter box. These queries usually have to be manually killed on Presto's side and then we apply the filter box from the dashboard which allows us to narrow into exactly the range we want to see with the specific partitions. If there is an existing functionality to tackle this I'm all ears, the only thing we saw as a potential stop gap was custom viz plugin hacks. |
This would be a huge improvement to the user experience. It would also make it possible to fix the filter while scrolling in the dashboard. Another great thing should be to save filter combinations. Sometimes users create complex filter combinations and they would like to look at data by repeating a previous filter configuration. |
it's happening! |
Implementing these suggestions would be highly valuable to improve user experience |
#12148 |
Closing this... it never really went through the SIP process of DISCUSS -> VOTE, but the work effectively happened :) @graceguo-supercat please re-open if I'm mistaken in any way, and/or you want to run it through the usual process. |
[SIP] Proposal for Dashboard Filter Component
Motivation
This SIP is not about design or implementation. Instead I want to discuss the requirements of dashboard filters: what functionalities the dashboard filters should offer. Based on this discussion, we will do architecture design and implementation plan.
Similar discussions: [SIP-9][SIP-25]
Over the last a few years, we got many, many suggestions and feature requests to improve the usability and interactions for Superset dashboard filters. Currently dashboard filters are charts, when it is loaded each filter field is a query (select DISTINCT column_name from table), and results are rendered as filter_box viz_type. It works good for most of use-cases, but still missed a few functionalities if compared with dashboard filter from other BI tools.
Proposed Change
I want to propose a solution to improve the functionalities for dashboard filters. Instead of using a separated slice component, I think dashboard should have build-in Filter component. It should carry over all the features from existed filter_box slice, understand properties that slice filter used (datasource, column, default values, sorting, .etc), and re-use dashboard specific properties, like filter scope and immune. All these filters related properties should be persistent in dashboard metadata.
For component UI/UX, we should follow SIP-34:
![6LmlSMwgEz](https://user-images.githubusercontent.com/27990562/87103811-e2473380-c20a-11ea-9e07-d471dc4b287f.gif)
view mode: apply filter
add/edit filter config and scopes
![Screen Shot 2020-07-09 at 5 35 56 PM](https://user-images.githubusercontent.com/27990562/87103807-deb3ac80-c20a-11ea-9fe4-796f12980bd6.png)
New or Changed Public Interfaces
I list all dashboard filters related feature requests here, so that we can decide which ones should be implemented.
Section 1: Current features should be kept:
Section 2: Extra filter functionalities candidates:
Section 3: Extra intra-dashboard interaction:
Migration Plan and Compatibility
Currently Superset filters for dashboard are slices, and all filter properties are stored in slices table. After we implemented dashboard filter component, existed filter slice should be converted to dashboard properties. We will offer a Superset db migration script, which will automatically convert filter_box properties into dashboard filter properties. But since each filter_box took some space in the dashboard, it will still need some manual work to remove filter_box from dashboard, and re-arrange dashboard layout to make it nice and clean.
Rejected Alternatives
Describe alternative approaches that were considered and rejected.
The text was updated successfully, but these errors were encountered: