mizunyang opened a new issue, #44680:
URL: https://github.com/apache/superset/issues/44680
### Bug description
## Bug description
In Apache Superset 6.1.0, a native `filter_time` can successfully produce a
selected `DataMask`, but the dashboard-level **Apply** button remains
disabled.
If the existing Apply callback is invoked, the dashboard charts are
re-queried
and the range is present in the Redux-applied `dataMask`. However, the filter
bar then displays `No filter` even though the charts are filtered, and
**Clear All** is disabled.
This appears to be a frontend state synchronization issue between
`dataMaskSelected` and `dataMaskApplied`.
This is related to native-filter state handling, but differs from #44530:
that issue concerns vertical Select filters after Clear All; this report
reproduces with a native **time** filter and affects the selected/applied
DataMask lifecycle.
## Steps to reproduce
1. Start Superset `6.1.0`.
2. Create a dashboard with one or more charts and a native Time Range filter
(`filterType: "filter_time"`).
3. Bind the filter explicitly to a real temporal column, for example:
```json
{
"targets": [
{
"datasetId": 10,
"column": { "name": "record_date" }
}
]
}
```
4. Open the dashboard.
5. Open the native time filter, select a preset such as **Current week** or
**Current month**, and click the popup-level **APPLY** button.
## Expected behavior
- The dashboard-level **Apply** button becomes enabled when the selected time
range differs from the applied range.
- Clicking dashboard-level **Apply** refreshes the affected charts.
- The selected range remains visible in the filter bar after it is applied.
- **Clear All** remains enabled while a time range is applied and clears the
range correctly.
## Actual behavior
Before applying a local workaround:
- The time-range label changes, for example to `Current month`.
- `dataMaskSelected` contains the selected range.
- The dashboard-level **Apply** button remains disabled.
- No chart-data request is issued from the normal dashboard-level Apply path.
When invoking the existing Apply callback directly for investigation:
- Chart-data requests are issued and charts are refreshed.
- Redux `dataMaskApplied` contains the selected time range.
- The filter bar subsequently changes to `No filter`.
- `dataMaskSelected` disappears.
- **Clear All** is disabled even though charts remain filtered.
## Environment
- Superset version: `6.1.0`
- Image base: `apache/superset:6.1.0`
- Browser: Chromium 153
- Native filter type: `filter_time`
- Filter bar orientation: reproduced with horizontal filter bar
- Temporal target: explicit dataset target using `record_date`
- Backend logs: no Python exception or server-side error observed
### Screenshots/recordings
_No response_
### Superset version
6.1.0
### Python version
Not applicable
### Node version
Not applicable
### Browser
Chrome
### Additional context
## Observed state
Immediately after selecting a range:
```js
dataMaskSelected = {
NATIVE_FILTER_EXAMPLE: {
id: "NATIVE_FILTER_EXAMPLE",
extraFormData: {
time_range: "Current month"
},
filterState: {
value: "Current month"
},
ownState: {}
}
}
```
At that point, the applied state is still empty:
```js
dataMaskApplied = {
NATIVE_FILTER_EXAMPLE: {
id: "NATIVE_FILTER_EXAMPLE",
extraFormData: {},
filterState: {},
ownState: {}
}
}
```
After applying through the existing callback:
```js
dataMaskApplied = {
NATIVE_FILTER_EXAMPLE: {
id: "NATIVE_FILTER_EXAMPLE",
extraFormData: {
time_range: "Current month"
},
filterState: {
value: "Current month"
},
ownState: {}
}
}
```
But the filter bar state becomes empty:
```js
dataMaskSelected = {}
```
As a result, the UI shows `No filter` and disables Clear All although charts
still reflect the applied time range.
## Additional investigation
The relevant code paths appear to be:
-
`superset-frontend/src/dashboard/components/nativeFilters/FilterBar/index.tsx`
- `checkIsApplyDisabled(...)`
- `handleApply(...)`
- synchronization between `dataMaskApplied` and `dataMaskSelected`
-
`superset-frontend/src/dashboard/components/nativeFilters/FilterBar/state.ts`
- `useFilterUpdates(...)`
The problem persists even after replacing an empty target definition
(`targets: [{}]`) with explicit dataset/column targets. Therefore, target
resolution is not sufficient to fix the selected-to-applied synchronization
problem.
## Proposed direction
The fix should preserve the following invariant:
> A native filter with non-empty `extraFormData` selected by the user must
> remain in `dataMaskSelected` until it is either applied, explicitly
cleared,
> or removed from the dashboard configuration.
In particular, please review whether the synchronization effect in
`FilterBar/index.tsx` can remove a newly selected native-filter DataMask
during
the transition from selected to applied state.
Potential acceptance tests:
1. Select a native time range, then verify dashboard-level Apply is enabled.
2. Apply the range, then verify the filter label still shows the selected
range.
3. Verify `dataMaskSelected` and `dataMaskApplied` both retain the time range
after applying.
4. Verify Clear All is enabled and clears the range.
5. Cover both explicitly targeted and default/empty-target native time-filter
configurations.
6. Verify no regression for chart customizations or required native filters.
## Checklist
- [x] I searched related issues, including #37069 and #44530.
- [x] I reproduced the issue on the released 6.1.0 image.
- [x] I verified that the selected range reaches `dataMaskSelected`.
- [x] I verified that normal UI Apply remains disabled.
- [x] I verified that applying the existing callback refreshes charts but can
clear the selected filter-bar state.
- [x] I checked server logs; this appears to be frontend-only.
### Checklist
- [x] I have searched Superset docs and Slack and didn't find a solution to
my problem.
- [x] I have searched the GitHub issue tracker and didn't find a similar bug
report.
- [x] 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.
--
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]
