ROX-34989: Add date range serialization and chip formatting utils#21050
ROX-34989: Add date range serialization and chip formatting utils#21050sachaudh wants to merge 1 commit into
Conversation
|
Skipping CI for Draft Pull Request. |
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Enterprise Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
🚀 Build Images ReadyImages are ready for commit 1294640. To use with deploy scripts: export MAIN_IMAGE_TAG=4.12.x-130-g1294640621 |
🚀 Build Images ReadyImages are ready for commit 0a32cb6. To use with deploy scripts: export MAIN_IMAGE_TAG=4.12.x-129-g0a32cb6e53 |
sachaudh
changed the title
The VM 2.0 date-picker filter only understands single-date values
(Before/On/After prefixes), so range values the backend already
supports (tr/<startMs>-<endMs>, 30d-90d, >365d) render as raw strings
in filter chips and cannot be produced by the UI.
Add the pure foundations for range support:
- serializeAbsoluteDateRange widens the picked dates to full calendar
days (start-of-day/end-of-day) so a range covers the days the user
selected, and emits the backend tr/ epoch-ms format.
- convertFromInternalToExternalDatePicker now renders human-readable
chips for absolute ranges ("Between Jan 01, 2025 and Mar 31, 2025"),
relative ranges ("Between 30 and 90 days ago"), and open-ended
relative values ("More than 365 days ago"). Malformed tr/ values
from untrusted URLs fall back to the original string instead of
being leniently parsed as a date.
- dateRangeCondition constant for the upcoming "Between" condition in
the date-picker dropdown; existing Before/On/After prefixes are
untouched to keep the single-date contract backward-compatible.
Signed-off-by: Saif Chaudhry <schaudhr@redhat.com>
sachaudh
force-pushed
the
ROX-34989-date-range-filter-utils
branch
from
0a32cb6 to
1294640
Compare
1 participant
Description
Jira: ROX-34989
This is the first slice of date/time range filtering for VM 2.0 (ROX-28073), stacked on #21049 which added the
ROX_VULN_MGMT_DATE_RANGE_FILTERfeature flag. The backend already supports range queries (tr/<startMs>-<endMs>for absolute ranges,30d-90dand>365dfor relative ones), but the UI's date-picker filter only understands single-date values. Range values arriving via URL (for example from the Aging Images dashboard widget) render as raw strings in filter chips, and there's no way to produce a range from the filter UI at all. I'm starting with the pure logic so the upcoming "Between" condition UI and the widget retarget have a tested foundation to build on.serializeAbsoluteDateRange(startMs, endMs), which widens the picked dates to full calendar days (start-of-day through end-of-day) and emits the backendtr/epoch-ms format. It throws on invalid dates or a start after the end, so callers can't silently apply a garbage filter.convertFromInternalToExternalDatePickerto render human-readable chips for all three range formats: "Between Jan 01, 2025 and Mar 31, 2025", "Between 30 and 90 days ago", and "More than 365 days ago".tr/value from an untrusted URL used to fall through tonew Date()and render as a nonsense date ("On Jan 01, 123"). It now falls back to the original string, matching the existing fallback behavior.dateRangeConditionconstant for the upcoming "Between" dropdown condition. The existing Before/On/After prefix handling is untouched, so the single-date contract is fully backward-compatible.Note: nothing is user-visible yet. These utils get consumed by the "Between" condition UI and the Aging Images widget retarget in follow-up PRs, all behind the feature flag.
User-facing documentation
Testing and quality
Automated testing
How I validated my change
utils.test.tspass, including the 8 pre-existing single-date tests, unmodified, which covers the backward-compatibility regression.npm run lint:fast-devclean on both touched files; fullnpm run tscclean.