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]

Reply via email to