Repository navigation
feat(filters): add a Calendar date picker option to the Time range filter - #44527
CodeWithPravinMaske wants to merge 26 commits into
Conversation
✅ Deploy Preview for superset-docs-preview ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
e845571 to
0a66df4
Compare
![bito-code-review[bot]](https://avatars.githubusercontent.com/in/1061978?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review Agent Run #2494c9
Actionable Suggestions - 4
-
superset-frontend/src/filters/components/DateRange/transformProps.ts - 1
- Unguarded queriesData destructure · Line 42-42
-
superset-frontend/src/filters/components/DateRange/controlPanel.ts - 1
- Dead control, no effect · Line 30-30
-
superset-frontend/src/filters/components/DateRange/utils.ts - 1
- Missing-separator date misparsed · Line 31-31
-
superset-frontend/src/constants.ts - 1
- Report drops new filter type · Line 203-203
Additional Suggestions - 2
-
superset-frontend/src/constants.ts - 1
-
URL rison misses date range · Line 203-203`convertRisonToNativeValue` (risonFilters.ts:476-499) has no `filter_date_range` case, so URL rison filters targeting a DateRange filter fall to the default branch and produce a `filters` array data mask, whereas the DateRange plugin emits `extraFormData.time_range`. Add a case so URL-applied date-range filters bind correctly.
-
-
superset-frontend/src/filters/components/DateRange/types.ts - 1
-
Unused defaultValue field · Line 28-30`defaultValue` is declared in `PluginFilterDateRangeCustomizeProps` and set in `DEFAULT_FORM_DATA`, but `DateRangeFilterPlugin.tsx` never reads `formData.defaultValue` (it only uses `filterState.value`), and `controlPanel.ts` exposes no control for it. Unlike sibling plugins (`Time`, `TimeColumn`, `TimeGrain`, `Select`) that consume `defaultValue`, this field is dead — configuring it has no effect. Wire it up or drop it.
-
Review Details
-
Files reviewed - 10 · Commit Range:
0a66df4..0a66df4- superset-frontend/src/constants.ts
- superset-frontend/src/filters/components/DateRange/DateRangeFilterPlugin.tsx
- superset-frontend/src/filters/components/DateRange/controlPanel.ts
- superset-frontend/src/filters/components/DateRange/index.ts
- superset-frontend/src/filters/components/DateRange/transformProps.ts
- superset-frontend/src/filters/components/DateRange/types.ts
- superset-frontend/src/filters/components/DateRange/utils.test.ts
- superset-frontend/src/filters/components/DateRange/utils.ts
- superset-frontend/src/filters/components/index.ts
- superset-frontend/src/visualizations/presets/MainPreset.ts
-
Files skipped - 0
-
Tools
- Whispers (Secret Scanner) - ✔︎ Successful
- Detect-secrets (Secret Scanner) - ✔︎ Successful
- Eslint (Linter) - ✔︎ Successful
Bito Usage Guide
Commands
Type the following command in the pull request comment and save the comment.
-
/review- Manually triggers an incremental AI Review. -
/review full- Manually triggers a full AI Review. -
/pause- Pauses automatic reviews on this pull request. -
/resume- Resumes automatic reviews. -
/resolve- Marks all Bito-posted review comments as resolved. -
/abort- Cancels all in-progress reviews.
Refer to the documentation for additional commands.
Configuration
This repository uses Superset You can customize the agent settings here or contact your Bito workspace admin at evan@preset.io.
Documentation & Help
AI Code Review powered by
|
Thanks for the review, @bito-code-review. Pushed a follow-up commit addressing feedback:
|
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #44527 +/- ##
=======================================
Coverage 84.68% 84.69%
=======================================
Files 3069 3072 +3
Lines 205463 205553 +90
Branches 48310 48346 +36
=======================================
+ Hits 174004 174088 +84
- Misses 28169 28176 +7
+ Partials 3290 3289 -1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Code Review Agent Run #c6366a
Actionable Suggestions - 6
-
superset/reports/models.py - 1
- Null time_range on cleared filter · Line 262-262
-
superset-frontend/src/filters/components/DateRange/types.ts - 1
- Dead contract field · Line 29-29
-
superset-frontend/src/filters/components/DateRange/DateRangeFilterPlugin.tsx - 1
- Unused filter option · Line 51-60
-
superset-frontend/src/filters/components/DateRange/controlPanel.ts - 1
- Duplicated control block · Line 30-38
-
superset-frontend/src/features/alerts/AlertReportModal.tsx - 2
- Magic format string · Line 1712-1712
- Cleared range persists null · Line 1715-1723
Additional Suggestions - 1
-
superset-frontend/src/filters/components/DateRange/utils.ts - 1
-
Magic number range count · Line 28-28`parts.length !== 2` hardcodes the range-endpoint count as a bare literal. Since `RANGE_SEPARATOR` and `DATE_FORMAT` are already named constants, the endpoint count should be too — a named constant documents that a range is exactly two parts and survives future edits (e.g. a separator appearing in a datetime).
-
Review Details
-
Files reviewed - 13 · Commit Range:
0a66df4..c937246- superset-frontend/src/constants.ts
- superset-frontend/src/features/alerts/AlertReportModal.tsx
- superset-frontend/src/filters/components/DateRange/DateRangeFilterPlugin.tsx
- superset-frontend/src/filters/components/DateRange/controlPanel.ts
- superset-frontend/src/filters/components/DateRange/index.ts
- superset-frontend/src/filters/components/DateRange/transformProps.ts
- superset-frontend/src/filters/components/DateRange/types.ts
- superset-frontend/src/filters/components/DateRange/utils.test.ts
- superset-frontend/src/filters/components/DateRange/utils.ts
- superset-frontend/src/filters/components/index.ts
- superset-frontend/src/visualizations/presets/MainPreset.ts
- superset/reports/models.py
- tests/unit_tests/reports/model_test.py
-
Files skipped - 0
-
Tools
- MyPy (Static Code Analysis) - ✔︎ Successful
- Astral Ruff (Static Code Analysis) - ✔︎ Successful
- Whispers (Secret Scanner) - ✔︎ Successful
- Detect-secrets (Secret Scanner) - ✔︎ Successful
- Eslint (Linter) - ✔︎ Successful
Bito Usage Guide
Commands
Type the following command in the pull request comment and save the comment.
-
/review- Manually triggers an incremental AI Review. -
/review full- Manually triggers a full AI Review. -
/pause- Pauses automatic reviews on this pull request. -
/resume- Resumes automatic reviews. -
/resolve- Marks all Bito-posted review comments as resolved. -
/abort- Cancels all in-progress reviews.
Refer to the documentation for additional commands.
Configuration
This repository uses Superset You can customize the agent settings here or contact your Bito workspace admin at evan@preset.io.
Documentation & Help
AI Code Review powered by
|
Interesting idea, to add another filter instead of changing the existing one. I see this discussion about the need for this: #19798 but don't immediately see any other PRs. Could you include screenshots of the new filter UI in your PR description? And how does this work with Jinja templating? |
|
@CodeWithPravinMaske since this is a new feature, can we add screenshots to the PR? |
|
Screenshots as requested: Adding the new filter type — "Date range filter" shows up in the Filter Type dropdown alongside the existing filter types (Value, Time range, Time column, Time grain, Numerical range):
The rendered filter bar control — a plain calendar date-range picker, no time-of-day fields, no No filter/Advanced/Relative/Previous options — filtering a real dashboard (note the dependent chart's data has changed to the selected range):
@sfirke re: Jinja templating — it works exactly like the Time Range filter, no special-casing needed. The filter emits Thanks for flagging the discussion thread (#19798) — this PR takes the "additive new filter type" path discussed there rather than modifying the existing Time Range filter, specifically so it doesn't change behavior for anyone already using Time Range. |
Adds a new native filter plugin ("Date range filter") that renders a
plain AntD RangePicker (no time-of-day, no relative/advanced/previous
options) and emits a standard time_range extraFormData value, so it
works as a drop-in alternative to the Time Range filter for dashboards
that only need a calendar date picker.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Fix parseTimeRange to reject a value missing the " : " separator instead of silently defaulting the missing end date to "now" (dayjs(undefined) is valid). - Add filter_date_range alongside filter_time in the Alerts & Reports scheduled-report filter serializer (superset/reports/models.py), so scheduled reports honor this filter the same way they do Time Range. - Add matching filter_date_range handling in AlertReportModal.tsx (skip column-value fetching, render a RangePicker for manual value entry) so configuring a scheduled report with this filter attached doesn't try to query it as a column-backed filter.
…tive_filter Codecov flagged the filter_date_range branch added in superset/reports/models.py as uncovered (0% patch coverage). Add the same normal-case and empty-values-warning tests already present for filter_time.
- Store an empty filterValues array (not [undefined]) when the Alerts & Reports date-range picker is cleared, so a cleared filter doesn't get serialized with a null time_range. - Use the exported DATE_FORMAT constant instead of a duplicated "YYYY-MM-DD" literal for the RangePicker format.
c937246 to
9929ef7
Compare
![codeant-ai-for-open-source[bot]](https://avatars.githubusercontent.com/u/151810221?s=60&v=4){kind=small}
| export function formatTimeRange(dates: DateRangeValue): string | undefined { | ||
| const [start, end] = dates ?? [null, null]; | ||
| if (!start || !end) return undefined; | ||
| return `${start.format(DATE_FORMAT)}${RANGE_SEPARATOR}${end.format(DATE_FORMAT)}`; |
There was a problem hiding this comment.
Suggestion: The selected end date is serialized at midnight, but Superset treats the upper time-range bound as exclusive, excluding the entire selected final calendar day.
Assessment: 🟠 Major · 🔁 Occurrence: Often · 🏷️ Logic error
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** superset-frontend/src/filters/components/DateRange/utils.ts
**Line:** 40:40
**Comment:**
*Logic Error: The selected end date is serialized at midnight, but Superset treats the upper time-range bound as exclusive, excluding the entire selected final calendar day.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fixThere was a problem hiding this comment.
✅ CodeAnt verified this suggestion was addressed in subsequent commits and marked this thread resolved as of b547203.
The formatter now adds one day to the selected end date before serializing it as the exclusive upper bound, and the parser subtracts one day when displaying it back.
If that's not right, unresolve this thread and CodeAnt will leave it open.
There was a problem hiding this comment.
✅ CodeAnt verified this suggestion was addressed in subsequent commits and marked this thread resolved as of 975dd5b.
The formatter now adds one day to the selected end date before serializing it as the exclusive upper bound, and the parser subtracts one day when displaying it back.
If that's not right, unresolve this thread and CodeAnt will leave it open.
There was a problem hiding this comment.
✅ CodeAnt verified this suggestion was addressed in subsequent commits and marked this thread resolved as of 654ab2c.
The formatter now adds one day to the selected end date before serializing it as the exclusive upper bound, and the parser subtracts one day when displaying it back.
If that's not right, unresolve this thread and CodeAnt will leave it open.
There was a problem hiding this comment.
✅ CodeAnt verified this suggestion was addressed in subsequent commits and marked this thread resolved as of afd4ab9.
The formatter now adds one day to the selected end date before serializing it as the exclusive upper bound, and the parser subtracts one day when displaying it back.
If that's not right, unresolve this thread and CodeAnt will leave it open.
There was a problem hiding this comment.
✅ CodeAnt verified this suggestion was addressed in subsequent commits and marked this thread resolved as of e06eaeb.
The formatter now adds one day to the selected end date before serializing it as the exclusive upper bound, and the parser subtracts one day when displaying it back.
If that's not right, unresolve this thread and CodeAnt will leave it open.
There was a problem hiding this comment.
✅ CodeAnt verified this suggestion was addressed in subsequent commits and marked this thread resolved as of 64a75a1.
The formatter now adds one day to the selected end date before serializing it as the exclusive upper bound, and the parser subtracts one day when displaying it back.
If that's not right, unresolve this thread and CodeAnt will leave it open.
There was a problem hiding this comment.
✅ CodeAnt verified this suggestion was addressed in subsequent commits and marked this thread resolved as of fc37b3e.
The formatter now adds one day to the selected end date before serializing it as the exclusive upper bound, and the parser subtracts one day when displaying it back.
If that's not right, unresolve this thread and CodeAnt will leave it open.
There was a problem hiding this comment.
✅ CodeAnt verified this suggestion was addressed in subsequent commits and marked this thread resolved as of b12786c.
The formatter now adds one day to the selected end date before serializing it as the exclusive upper bound, and the parser subtracts one day when displaying it back.
If that's not right, unresolve this thread and CodeAnt will leave it open.
There was a problem hiding this comment.
✅ CodeAnt verified this suggestion was addressed in subsequent commits and marked this thread resolved as of 878271e.
The formatter now adds one day to the selected end date before serializing it as the exclusive upper bound, and the parser subtracts one day when displaying it back.
If that's not right, unresolve this thread and CodeAnt will leave it open.
Superset's time_range filter treats the upper bound as exclusive (col < end_dttm, see get_time_filter in superset/models/helpers.py) — the same reason the built-in Custom time-range picker labels its fields "Start (inclusive)" / "End (exclusive)". Our plain date-only picker has no such labeling, so a user picking an end date expects that whole day to be included. Store the end bound as one day past the selected end date so the entire selected day is covered, and reverse that offset on parse so re-opening the filter displays the originally picked date.
Code Review Agent Run #7afa77Actionable Suggestions - 0Additional Suggestions - 3
Review Details
Bito Usage GuideCommands Type the following command in the pull request comment and save the comment.
Refer to the documentation for additional commands. Configuration This repository uses Documentation & Help AI Code Review powered by |
rusackas
left a comment
rusackas
left a comment
There was a problem hiding this comment.
Heya @CodeWithPravinMaske, thanks for sticking with this through a couple rounds of review, most of the bot findings turned out to already be addressed and I went ahead and resolved those threads.
Two things left before this is mergeable. CI's actually red right now: messages.pot is out of sync since "Date range filter" and its description never got regenerated into the template, that's ./scripts/translations/babel_update.sh and a commit of the result.
The other one's real: enableEmptyFilter ("Filter value is required") is exposed in the control panel but nothing reads it, not DateRangeFilterPlugin.tsx, not transformProps.ts. A dashboard builder can toggle it on and get no enforcement at all, which is worse than not having the option since it looks like it's doing something. RangeFilterPlugin and SelectFilterPlugin both honor this flag already, might be worth mirroring one of those.
Everything else (the exclusive-end-date handling, report/alert integration) looks solid. Let me know once those two are sorted and I'll take another pass.
- Run ./scripts/translations/babel_update.sh to add "Date range filter" and its description to messages.pot and all language catalogs — these were never extracted after the filter was added. - Pass filterState.validateStatus through to the RangePicker's status prop, so a required-and-empty filter shows a red border like RangeFilterPlugin/SelectFilterPlugin already do. Apply-blocking itself was already enforced generically by the filter bar framework (verified live); this only adds the missing visual feedback.
github-actions
Bot
added
i18n
|
I think this is REALLY close to appeasing #26651 It'd be good to see what the delta is between that SIP and this implementation. We can move that SIP to a vote once we see if I'm right about their potential alignment. |
|
@rusackas Took a look at SIP-116 (#26651) against this PR — here's the delta:
So functionally this looks like a close match for the SIP's intent. The one gap: the SIP doesn't explicitly ask for removing time-of-day, but that fell out naturally from using a plain date picker rather than a datetime one — seems like a reasonable bonus simplification rather than a divergence. Happy to adjust anything if you see this differently before it goes to a vote. |
rusackas
left a comment
rusackas
left a comment
There was a problem hiding this comment.
Correcting myself from last pass: I called enableEmptyFilter a dead control, but that was wrong. Checked the framework layer this time, FilterControl.tsx/FilterBar enforce it centrally off controlValues.enableEmptyFilter regardless of whether the plugin component reads it, exactly like Time (which this PR explicitly mirrors) already does. Not a bug.
Everything else bot-flagged is resolved, and the pot-drift CI failure from last time is cleared. Approving!
The only thing standing between this and merge is hold:sip!, and that's a good thing to have blocking, not a code issue. Given the SIP-116 delta looks like a strong match, I'll leave a note on the SIP issue itself linking here so that conversation can move toward a vote.
github-actions
Bot
added
the
requires:rebase
| const [start, end] = dates ?? [null, null]; | ||
| if (!start || !end) return undefined; | ||
| const exclusiveEnd = end.add(1, 'day'); | ||
| return `${start.format(DATE_FORMAT)}${RANGE_SEPARATOR}${exclusiveEnd.format(DATE_FORMAT)}`; |
There was a problem hiding this comment.
this will stick to absolute dates only, won't it? i.e. if I leave a filter to "last 30", wont it freeze to those last 30 days forever?
There was a problem hiding this comment.
@andy-clapson Good catch, and correct — this is absolute-dates-only by design, not a bug. The picker only ever produces literal calendar dates (YYYY-MM-DD : YYYY-MM-DD), never a relative expression, so a "last 30 days" selection freezes to those specific dates and won't roll forward. That's intentional: the whole point of this filter is to be the plain-calendar counterpart to the existing Time Range filter, which already covers relative/rolling windows via its Advanced tab. Anyone who needs a rolling "last N days" filter should use Time Range instead — this one's additive, not a replacement, so that option isn't going away. Happy to call this out explicitly in the docs/PR description if it'd help avoid confusion for future users.
There was a problem hiding this comment.
Can we not have both advanced options and calendar picker in a single filter? The reason is if we need to provide advanced flexibility to end users, wouldn't it be easier to have a single filter than choosing between 2?
There was a problem hiding this comment.
@krmmkr Fair question, and it was a real design fork.
Why this filter exists at all: the existing Time Range filter's multi-tab UI (No filter / Advanced / Relative / Previous / Custom with time) is flexible but overwhelming for the common case of "just pick a start and end date" — that's the whole motivation behind SIP-116 (#26651), which this PR is aiming to satisfy. So this filter is intentionally the plain-calendar counterpart: pick a date, pick a date, done.
Why no advanced options here: that functionality already exists in the Time Range filter — relative ranges, "No filter," previous-period comparison, advanced expressions, all of it. Duplicating that inside this filter wouldn't add any new capability, it'd just be two filters doing the same thing with more surface area to maintain, and it'd reintroduce the exact complexity/discoverability problem the SIP was trying to get away from. If a dashboard needs both simple and advanced audiences, the two filter types can sit side by side rather than merging into one.
We're not planning to change that in this PR. If there's real appetite for it later, that's a reasonable follow-up enhancement to scope separately (possibly via the SIP-116 thread) rather than something to fold in now.
There was a problem hiding this comment.
Hey @krmmkr I agree, and I just posted a new comment on SIP-116 suggesting we move toward that in the course of two PRs.
There was a problem hiding this comment.
This would also address what @andy-clapson writes above.
…ive-filter # Conflicts: # superset/translations/ar/LC_MESSAGES/messages.po # superset/translations/ca/LC_MESSAGES/messages.po # superset/translations/cs/LC_MESSAGES/messages.po # superset/translations/de/LC_MESSAGES/messages.po # superset/translations/en/LC_MESSAGES/messages.po # superset/translations/es/LC_MESSAGES/messages.po # superset/translations/fa/LC_MESSAGES/messages.po # superset/translations/fi/LC_MESSAGES/messages.po # superset/translations/fr/LC_MESSAGES/messages.po # superset/translations/it/LC_MESSAGES/messages.po # superset/translations/ja/LC_MESSAGES/messages.po # superset/translations/ko/LC_MESSAGES/messages.po # superset/translations/lv/LC_MESSAGES/messages.po # superset/translations/messages.pot # superset/translations/mi/LC_MESSAGES/messages.po # superset/translations/nl/LC_MESSAGES/messages.po # superset/translations/pl/LC_MESSAGES/messages.po # superset/translations/pt/LC_MESSAGES/messages.po # superset/translations/pt_BR/LC_MESSAGES/messages.po # superset/translations/ro/LC_MESSAGES/messages.po # superset/translations/ru/LC_MESSAGES/messages.po # superset/translations/sk/LC_MESSAGES/messages.po # superset/translations/sl/LC_MESSAGES/messages.po # superset/translations/sr/LC_MESSAGES/messages.po # superset/translations/sr_Latn/LC_MESSAGES/messages.po # superset/translations/ta/LC_MESSAGES/messages.po # superset/translations/th/LC_MESSAGES/messages.po # superset/translations/tr/LC_MESSAGES/messages.po # superset/translations/uk/LC_MESSAGES/messages.po # superset/translations/zh/LC_MESSAGES/messages.po # superset/translations/zh_TW/LC_MESSAGES/messages.po
…ive-filter # Conflicts: # superset/translations/ar/LC_MESSAGES/messages.po # superset/translations/ca/LC_MESSAGES/messages.po # superset/translations/cs/LC_MESSAGES/messages.po # superset/translations/de/LC_MESSAGES/messages.po # superset/translations/en/LC_MESSAGES/messages.po # superset/translations/es/LC_MESSAGES/messages.po # superset/translations/fa/LC_MESSAGES/messages.po # superset/translations/fi/LC_MESSAGES/messages.po # superset/translations/fr/LC_MESSAGES/messages.po # superset/translations/it/LC_MESSAGES/messages.po # superset/translations/ja/LC_MESSAGES/messages.po # superset/translations/ko/LC_MESSAGES/messages.po # superset/translations/lv/LC_MESSAGES/messages.po # superset/translations/messages.pot # superset/translations/mi/LC_MESSAGES/messages.po # superset/translations/nl/LC_MESSAGES/messages.po # superset/translations/pl/LC_MESSAGES/messages.po # superset/translations/pt/LC_MESSAGES/messages.po # superset/translations/pt_BR/LC_MESSAGES/messages.po # superset/translations/ro/LC_MESSAGES/messages.po # superset/translations/ru/LC_MESSAGES/messages.po # superset/translations/sk/LC_MESSAGES/messages.po # superset/translations/sl/LC_MESSAGES/messages.po # superset/translations/sr/LC_MESSAGES/messages.po # superset/translations/sr_Latn/LC_MESSAGES/messages.po # superset/translations/ta/LC_MESSAGES/messages.po # superset/translations/th/LC_MESSAGES/messages.po # superset/translations/tr/LC_MESSAGES/messages.po # superset/translations/uk/LC_MESSAGES/messages.po # superset/translations/zh/LC_MESSAGES/messages.po # superset/translations/zh_TW/LC_MESSAGES/messages.po
|
@andy-clapson @krmmkr thanks for the feedback. I replied on your threads (absolute dates only by design; a relative/advanced mode could come later as an opt-in toggle). Does that answer your questions, or would you want something changed in this PR before it goes ahead? If you're fine with it, please resolve your threads. @rusackas the branch is rebased on the latest master, the only open item is the |
Code Review Agent Run #d98d8fActionable Suggestions - 0Additional Suggestions - 40
Filtered by Review RulesBito filtered these suggestions based on rules created automatically for your feedback. Manage rules.
Review Details
Bito Usage GuideCommands Type the following command in the pull request comment and save the comment.
Refer to the documentation for additional commands. Configuration This repository uses Documentation & Help AI Code Review powered by |
…ive-filter # Conflicts: # superset/translations/ar/LC_MESSAGES/messages.po # superset/translations/ca/LC_MESSAGES/messages.po # superset/translations/cs/LC_MESSAGES/messages.po # superset/translations/de/LC_MESSAGES/messages.po # superset/translations/en/LC_MESSAGES/messages.po # superset/translations/es/LC_MESSAGES/messages.po # superset/translations/fa/LC_MESSAGES/messages.po # superset/translations/fi/LC_MESSAGES/messages.po # superset/translations/fr/LC_MESSAGES/messages.po # superset/translations/it/LC_MESSAGES/messages.po # superset/translations/ja/LC_MESSAGES/messages.po # superset/translations/ko/LC_MESSAGES/messages.po # superset/translations/lv/LC_MESSAGES/messages.po # superset/translations/messages.pot # superset/translations/mi/LC_MESSAGES/messages.po # superset/translations/nl/LC_MESSAGES/messages.po # superset/translations/pl/LC_MESSAGES/messages.po # superset/translations/pt/LC_MESSAGES/messages.po # superset/translations/pt_BR/LC_MESSAGES/messages.po # superset/translations/ro/LC_MESSAGES/messages.po # superset/translations/ru/LC_MESSAGES/messages.po # superset/translations/sk/LC_MESSAGES/messages.po # superset/translations/sl/LC_MESSAGES/messages.po # superset/translations/sr/LC_MESSAGES/messages.po # superset/translations/sr_Latn/LC_MESSAGES/messages.po # superset/translations/ta/LC_MESSAGES/messages.po # superset/translations/th/LC_MESSAGES/messages.po # superset/translations/tr/LC_MESSAGES/messages.po # superset/translations/uk/LC_MESSAGES/messages.po # superset/translations/zh/LC_MESSAGES/messages.po # superset/translations/zh_TW/LC_MESSAGES/messages.po
…ive-filter # Conflicts: # superset-frontend/src/features/alerts/AlertReportModal.tsx # superset/translations/messages.pot
|
…time range
The Calendar range pill showed the backend range ("2026-10-01 ≤ col < 2026-12-01"), so picking Nov 30 displayed "less than Dec 1". Show the days the user picked ("2026-11-01 – 2026-11-30"); the exact backend range stays in the tooltip.
SUMMARY
Adds a Calendar date picker option (a checkbox, off by default) to the existing Time range native filter, following the direction agreed in SIP-116 (#26651).
CalendarRangePicker) inDateFilterControl/components, so the SIP's Part 1 (a Calendar choice in the time range control, including Explore) can reuse it.This replaces the earlier approach of a separate
filter_date_rangefilter type, which is removed along with its Alerts & Reports handling.BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
(attach: the checkbox in the filter settings; the calendar in the filter bar; the filter with the option off)
TESTING INSTRUCTIONS
ADDITIONAL INFORMATION