john-bodley opened a new issue #9935: URL: https://github.com/apache/incubator-superset/issues/9935
## [SIP] Proposal for signifying if a dashboard filter does not apply to a chart ### Motivation Currently a user can configure dashboard filters to either apply or not apply to specific charts. For the former, i.e., non-immune charts, there is no validation on whether the filter is eligible for the specific chart and currently if the filter is deemed irrelevant it is simply ignored by the chart. The issue with this approach is there is no visual indication that the chart has ignored said filter(s) and thus the viewer could be misguided into believing a set of filters have been applied, thus making an incorrect conclusion. This SIP proposes new visual treatments for handling filters which are enabled but are not relevant to the chart (Figure 1). Description of the problem to be solved. ### Proposed Change #### Visualizations There are two different states/scenarios we need to consider in order to provide the appropriate UX: 1. A user is interacting with a dashboard chart where during a prior state the chart was deemed correct however after applying a filter the chart is deemed incorrect. 2. A user is interacting with a dashboard chart where an existing (possibly saved) filter has been applied where the chart is deemed incorrect. Note there is no prior valid state for the chart. The lefthand portion of Figure 1 illustrates these two states. The upper-left corner shows the treatment for (1) where the previously rendered chart is greyed out (via an opacity layer) and a message is show. The lower-left corner shows the treatment for (2) where since there was no prior valid state only the message is shown. The upper-right portion of the figure provides context as to which filters don't apply (which contain an exclamation point), and the lower-right portion shows the message treatment being applied to a smaller chart. <img width="1190" alt="Filters_safe" src="https://user-images.githubusercontent.com/4567245/83078812-446b2100-a02f-11ea-8008-af324887575f.png"> **Figure 1:** The various visual treatments for handling filters which do not apply to a chart. The lefthand portion illustrates the the two different states, the upper-right portion provides context as to which filters don't apply (which contain an exclamation point), and the lower-right portion shows the message treatment being applied to a smaller chart. Describe how the feature will be implemented, or the problem will be solved. If possible, include mocks, screenshots, or screencasts (even if from different tools). ### New or Changed Public Interfaces In order for the frontend to know if a filter can be applied a new RESTful endpoint needs to be added which would leverage the metadata of the underlying datasource. Note this approach provides a better UX and saves trying to execute the query unnecessarily. The one caveat of this approach is the [`filter_values`](https://github.com/apache/incubator-superset/blob/7f6dbf838e4e527e640a002ce20bf5da1abf4a98/superset/jinja_context.py#L37) Jinja macro, which per the documentation states: > This is useful if: > - you want to use a filter box to filter a query where the name of filter box > column doesn't match the one in the select statement > - you want to have the ability for filter inside the main query for speed purposes This could be problematic because it is not viable to determine whether the filter is applicable by simply inspecting the column/metric metadata of the underlying datasource. There are two approaches to remedying this problem: 1. Extend the metadata to include the SQL for virtual datasources which needs to be parsed. 2. Deprecate the `filter_values` Jinja macro. The first point can be circumvented by adding a virtual column (alias) to a SQL datasource which adheres to the filter where the expression is merely the name of the corresponding column. The second point cannot be circumvented resulting in sub-optimal queries. Note for context < 0.1% of SQL datasources and < 0.1% of slices at Airbnb use the `filter_values` macro. ### New dependencies N/A. ### Migration Plan and Compatibility N/A. ### Rejected Alternatives Describe alternative approaches that were considered and rejected. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
