sadpandajoe commented on code in PR #39683:
URL: https://github.com/apache/superset/pull/39683#discussion_r3828531377
##########
superset/common/query_object_factory.py:
##########
@@ -138,16 +139,20 @@ def _process_time_range(
if flt.get("op") == FilterOperator.TEMPORAL_RANGE
]
if temporal_flt:
- # Use the temporal filter as the time range.
- # if the temporal filters uses x-axis as the temporal filter
- # then use it or use the first temporal filter
- x_axis_label = get_x_axis_label(columns)
+ # Prefer TEMPORAL_RANGE on the chart x-axis (BASE_AXIS). Do
not blindly use
+ # temporal_flt[0]: it may be another datetime (e.g. dashboard
filter on event_b
+ # while the chart axis is event_a), which would drive wrong
from_dttm/to_dttm.
+ x_axis_label = get_x_axis_label(columns or [])
match_flt = [
- flt for flt in temporal_flt if flt.get("col") ==
x_axis_label
+ flt
+ for flt in temporal_flt
+ if get_query_object_filter_column_name(flt.get("col"))
Review Comment:
This now compares a filter's `sqlExpression` to the BASE_AXIS label, so an
adhoc axis whose label differs from its SQL expression no longer selects its
own time range. The existing `test_process_time_range.py` fixture has `label:
dttm2`, `sqlExpression: dttm`, and a `dttm2` temporal filter; this path falls
through to `NO_TIME_RANGE`, leaving `from_dttm`/`to_dttm` unset. Should both
sides use the same normalized identifier?
--
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]
