rumbin opened a new issue, #26194:
URL: https://github.com/apache/superset/issues/26194
Dashboard filters that _only_ become effective in nested/references
datasets, i.e., `select ... from {{ dataset(123) }}', are correctly applied in
the query but are not reflected in the filter indicator.
#### How to reproduce the bug
1. Create a virtual dataset which applies some push-down filtering via
`filter_values('my_column')`
2. Create another virtual dataset which selects from the previously created
dataset and which does _not_ contain this column `my_column`, neither as an
output column nor via `filter_values()` evaluation.
3. Create a chart on the second dataset and place it on a dashboard.
4. Add a filter on `my_column` to the dashboard-native filters.
5. Apply a filter on `my_column` on the dashboard.
### Expected results
* The `my_column` filter is being injected into the chart's query.
* The filter indicator reflects that the `my_column` filter is being applied
to the chart on our dashboard.
### Actual results
* Good: The `my_column` filter is actually being injected into the chart's
query.
* Bad: The filter indicator noes _not_ reflect that the `my_column` filter
is being applied to the chart on our dashboard.
#### Screenshots
Real-life example:
Filter indicator shows only a few filters applied:
The compiled/executed query confirms that all filters actually got injected
This is how we referenced the dataset:
And this is the relevant part of `dataset(123)`:
### Environment
(please complete the following information):
- browser type and version:
- superset version: 3.0.2
- python version: `python --version`
- node.js version: `node -v`
- any feature flags active:
### Checklist
Make sure to follow these steps before submitting your issue - thank you!
- [x] I have checked the superset logs for python stacktraces and included
it here as text if there are any.
- [x] I have reproduced the issue with at least the latest released version
of superset.
- [x] I have checked the issue tracker for the same issue and I haven't
found one similar.
### Additional context
Side note:
The `where_column_in()` Jinja function shown in the last screenshot is a
NULL-safe custom function of ours. It should not have any influence on the
reported issue, imho.
--
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.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
