ROX-34990: Add Between date range condition to date filter input#21051
Open
sachaudh wants to merge 9 commits into
Open
ROX-34990: Add Between date range condition to date filter input#21051sachaudh wants to merge 9 commits into
sachaudh wants to merge 9 commits into
Conversation
Users could only filter VM 2.0 results by a single date (Before/On/After). Add an opt-in Between condition to SearchFilterConditionDate that reveals two date pickers wired per the PatternFly date-range pattern: the end picker stays disabled until the start date is valid, defaults to the day after the start date, highlights the range via rangeStart, and rejects an end date before the start date with an inline validator. Applying emits the backend time-range format tr/<startMs>-<endMs> via serializeAbsoluteDateRange instead of the single-date prefix format. The condition is hidden behind the isBetweenEnabled prop (default false) so behavior is unchanged until the feature flag wiring passes it in, and the Before/On/After branches are untouched. Component test covers the prop gating, range apply, same-day range, validator, and single-date regression. Signed-off-by: Saif Chaudhry <schaudhr@redhat.com>
Read ROX_VULN_MGMT_DATE_RANGE_FILTER once in the date-picker dispatcher and pass isBetweenEnabled down, so the Between condition appears on every date-picker attribute when the flag is on and behavior is byte-identical to today when it is off. The flag is read in CompoundSearchFilterInputField rather than the leaf input so the leaf stays a pure presentational component that is testable without context. Wrap the CompoundSearchFilter component test in a mock FeatureFlagsContext provider (pattern from ImageComponentVulnerabilitiesTable.cy.jsx) because the dispatcher now requires the context, and cover both flag states. Signed-off-by: Saif Chaudhry <schaudhr@redhat.com>
|
Skipping CI for Draft Pull Request. |
Contributor
|
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 |
Contributor
🚀 Build Images ReadyImages are ready for commit c971372. To use with deploy scripts: export MAIN_IMAGE_TAG=4.12.x-139-gc971372587 |
The dispatcher-level feature-flag check coupled the generic CompoundSearchFilter library to a VM-specific flag and enabled the new Between condition on non-VM surfaces (Violations, Clusters, Policies) that the spec marks out of scope. Replace it with a typed DatePickerSearchFilterAttribute carrying optional inputProps.enableBetweenCondition, following the condition-text precedent, so each surface opts in per attribute and the library carries no feature-flag knowledge. Component tests no longer need a mock FeatureFlagsContext. Between is temporarily unreachable in the product UI until the VM layer applies the opt-in behind the flag (follow-up commit). Signed-off-by: Saif Chaudhry <schaudhr@redhat.com>
SearchFilterConditionDate had grown to four state variables, a branching apply handler, and duplicated DatePicker blocks to serve two distinct input shapes. Splitting the bodies into SearchFilterDateSingle and SearchFilterDateRange gives each input shape its own state, validation, and apply handler, so the parent only owns the condition selection. This keeps the upcoming relative-age work (ROX-28073 stretch) from growing the same component further. Shared date parsing and formatting helpers move to utils/dateInput so both bodies use identical strict MM/DD/YYYY handling. Behavior and aria-labels are unchanged; both Cypress component specs pass without selector changes. Signed-off-by: Saif Chaudhry <schaudhr@redhat.com>
Apply the Between opt-in in AdvancedFiltersToolbar behind ROX_VULN_MGMT_DATE_RANGE_FILTER instead of inside the generic CompoundSearchFilter library. The previous dispatcher-level flag check leaked the new condition onto every surface with a date-picker attribute (Violations, Clusters, Policies), which the spec scopes out and whose time-range query handling is untested. The enableDateRangeConditions mapper spread-copies entities and date-picker attributes because the attribute objects are shared module constants that other surfaces render directly. The Image Vulnerability Report wizard intentionally keeps Before/On/After only; its toolbar does not pass through this mapper. Signed-off-by: Saif Chaudhry <schaudhr@redhat.com>
Editing the start date previously clobbered an end date the user had already picked, resetting it to the day after the new start (or clearing it while the start was mid-edit). Only default the end date when it is empty or would fall before the new start, so corrections to the start date no longer discard the user's selection. Signed-off-by: Saif Chaudhry <schaudhr@redhat.com>
enableDateRangeConditions deliberately spreads existing inputProps so date-picker attributes can gain other props later; the strict toEqual assertion would start failing as soon as one does. Signed-off-by: Saif Chaudhry <schaudhr@redhat.com>
The memo keyed on a prop that callers recreate on every render, so it never avoided recomputation; the config mapping is cheap enough to run inline. Signed-off-by: Saif Chaudhry <schaudhr@redhat.com>
The length guard in dateParse already requires exactly 2/2/4 digit segments, so the padStart calls were dead code that suggested padding could happen. Use the literal 'On' for the default date condition so it is type-checked against DateCondition instead of depending on key order in dateConditionMap. Signed-off-by: Saif Chaudhry <schaudhr@redhat.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Jira: ROX-34990
This is the next slice of the VM 2.0 date range filtering work (ROX-28073), stacked on top of #21050 which added the range serialization utils. Right now the date filter input only supports single-date conditions ("Before", "On", "After"), so there's no way to scope results to a window of time. This PR adds a "Between" condition that lets users pick a start and end date.
tr/<startMs>-<endMs>(start of day to end of day) usingserializeAbsoluteDateRangefrom ROX-34989: Add date range serialization and chip formatting utils #21050SearchFilterDateSingleandSearchFilterDateRangebody components, each owning its own state and validation, with shared date parsing helpers inutils/dateInput.tsinputProps(DatePickerSearchFilterAttributewithenableBetweenCondition, following the existingcondition-textprecedent), so the generic CompoundSearchFilter library stays feature-flag-freeROX_VULN_MGMT_DATE_RANGE_FILTERflag is applied in the vulnerability layer:AdvancedFiltersToolbarmaps its config throughenableDateRangeConditionswhen the flag is on. This scopes Between to vulnerability list views only; other surfaces that reuse the same date-picker attributes (Violations, Clusters, Policies) and the Image Vulnerability Report wizard keep Before/On/After. With the flag off, the condition selector is unchanged everywhereSearchFilterConditionDateand extended theCompoundSearchFilterspec with config-driven tests covering attributes with and without the Between opt-inUser-facing documentation
Testing and quality
Automated testing
How I validated my change
SearchFilterConditionDate.cy.jsx, 14 inCompoundSearchFilter.cy.jsx, including the 2 config-driven Between opt-in tests)enableDateRangeConditionsmapper (3 tests: enables Between on date-picker attributes only, returns copies, never mutates the shared attribute constants)ROX_VULN_MGMT_DATE_RANGE_FILTER, go to a vulnerability page with a date filter attribute (for example Vulnerability Management CVEs with "Discovered time"), open the condition selector, and pick "Between". Pick a start date, confirm the end date defaults to the next day, apply, and check that the filter chip shows the range. With the flag off, the selector should only show "Before"/"On"/"After". Non-vulnerability pages with date filters (for example Violations) should never show "Between", flag on or offScreenshots / Screen recordings
Click on "Between" to show two date pickers. The second is disabled until the first is selected.
When the first is selected, you can choose any date from that date forward. Days before the start date are disabled.
When you click on the "Submit" button, the chip/label will show up with human-readable text.
Screen Recording of the flow
Screen.Recording.2026-06-09.at.9.57.11.PM.mov