rumbin opened a new issue #3617: Carry over dashboard filters to explore: 
conflicting use cases
URL: https://github.com/apache/incubator-superset/issues/3617
 
 
   ### Preface
   This is about the changes introduced by virtue of #3461 (Superset version 
0.20.3).
   
   ### Description
   In my understanding there are at least two use cases for the _Explore chart_ 
functionality of a dashboard's slice. Without respection any order of 
importance, these are:
   
   1. Analyze the currently displayed chart data in more detail, maybe for 
applying more filters or adding some more grouping criteria. In this case the 
transfer of currently set dashboard filters to the expolre view is a behavior 
that is expected by (less experienced) users. I.e. the currently implemented 
behavior is ? apart from issue #3616 ? highly welcome.
   2. Alter/fix something on the slice _permanently, like maybe a missing axis 
label, a badly chosen bottom margin or whatever. So after altering the slice, 
the changes are made permanent by overwriting the current slice. In this use 
case, the user has te be very careful and find out if there are any filters in 
explore view that exist _only_ due to the transfer of the dashboard filters and 
then remove these filters. Otherwise they _introduce unwanted filters_ without 
even knowing.
   
   I can perfectly understand both use cases. In both use cases we risk 
unexpected behavior. However, in the second one there is a high risk of 
concealed degradation, as especially routined superset users may not expect 
this change in behavior. Even if thy were aware of it, they would be required 
to know their slices very well, in order to understand which of the applied 
filters in explore view have been there before opening the slice from a 
filtered dashboard. Furthermore, together with issue #3616, this may become 
fairly annoying.
   
   ### Solution
   To be honest, I don't see any other option than maybe asking the user 
whether they want to transfer the filters when clicking _Explore chart_. I must 
admit, however, that this is not an elegant solution.
   
   What do you think about this issue?
 
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
[email protected]


With regards,
Apache Git Services

Reply via email to