Unable to order filters inherited from dashboard.

[jhastingsiii]

Bug description

Apologies in advance if this is something that can be done, but I've not been able to figure it out to find any references that says it can be done.

My users build a number of dashboards and almost always use temporal filters. But these filters are always applied after local chart filters which means my indexes on the date columns don't get used properly. If I edit a chart and drag up the filter inherited from the dashboard, saving the chart will just revert the filters back to their positions from the inherited dashboard, it will never apply properly. The WHERE condition in the SQL shows the dashboard filter in the query last which avoids my index.

If there's something I've missed somewhere that will allow me to do this or workaround it, I would greatly appreciate it.

Screenshots/recordings

No response

Superset version

master / latest-dev

Python version

3.9

Node version

16

Browser

Chrome

Additional context

No response

Checklist

• I have searched Superset docs and Slack and didn't find a solution to my problem.
• I have searched the GitHub issue tracker and didn't find a similar bug report.
• I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.

[dosubot[bot]]

Hi @jhastingsiii! I'm Dosu and I'm helping the Apache Superset team.

Unfortunately, there is currently no way to control the ordering of inherited dashboard filters relative to chart-level filters in the WHERE clause. Here's why:

Dashboard filters are merged into the chart's adhoc_filters array (marked with an isExtra flag) before SQL generation begins [1]. When the query is built, all filters in that combined array are processed sequentially and joined with AND logic [2]. Dashboard filters are appended to the end of the array during merging, which is why they appear last in your WHERE clause.

The overall WHERE clause order is:

1. Adhoc filters (chart-level first, then dashboard-inherited)
2. Row Level Security filters
3. extras.where clauses
4. Time range filters (if granularity is set)

[3]

Regarding your index concern: Since all conditions are combined with AND, the SQL engine's query optimizer should be able to use appropriate indexes regardless of the filter order in the WHERE clause — the textual order of AND predicates generally doesn't determine index usage for most databases (PostgreSQL, MySQL, etc.). The query planner evaluates all predicates and picks the best execution plan.

If your database isn't using your temporal index, the issue is more likely related to:

• Query planner statistics being stale (try ANALYZE on the table)
• The temporal filter expression not being sargable (e.g., wrapping the column in a function)
• The optimizer deciding a full scan is cheaper given the selectivity

Workaround: If you absolutely need the temporal filter to appear first in the WHERE clause for a specific database engine that is sensitive to predicate order, you could define the temporal filter directly on the chart (as a chart-level adhoc filter) rather than relying on the inherited dashboard filter. Chart-level filters are processed before dashboard-inherited ones in the combined array.

This is a limitation in the current architecture since there's no API or UI to reorder inherited filters.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[jhastingsiii]

Maybe this would be a feature-request rather than a bug if it's intended/known the dashboard filters can't be prioritized for the order.