ROX-34994: Add ROX_VULN_MGMT_DATE_RANGE_FILTER feature flag#21049
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 831ef90. To use with deploy scripts: export MAIN_IMAGE_TAG=4.12.x-129-g831ef90243 |
Date/time range filtering for VM 2.0 advanced filters will land in increments, so gate the upcoming "Between" condition and the Aging Images widget retarget behind a flag that is disabled by default in production and enabled in CI e2e runs, following the same pattern as ROX_NODE_VULNERABILITY_REPORTS (#19929). Signed-off-by: Saif Chaudhry <schaudhr@redhat.com>
f1fbca9 to
212f342
Compare
Description
Jira: ROX-34994
I'm starting on date/time range filtering for the VM 2.0 advanced filters (a "Between" condition on the date-picker attributes, plus retargeting the Aging Images dashboard widget from VM 1.0 to VM 2.0). I'm planning to land that work in incremental PRs, so this first one just adds the feature flag to keep the in-progress pieces hidden until everything is ready. I followed the same pattern we used in #19929 for
ROX_NODE_VULNERABILITY_REPORTS.VulnMgmtDateRangeFilter(ROX_VULN_MGMT_DATE_RANGE_FILTER) inpkg/features/list.go, disabled by defaulttests/e2e/lib.sh:export_test_environmentanddeploy_central_via_operator)FeatureFlagEnvVarunion in the UI (types/featureFlag.ts)Nothing reads the flag yet, so there's no behavior change anywhere with this PR.
User-facing documentation
Testing and quality
Automated testing
I didn't check any boxes here since this is flag registration only, with no new logic to test. The flag's actual behavior will get unit and component tests in the follow-up PRs that consume it.
How I validated my change
go build ./pkg/features/...andgo test ./pkg/features/..., both passbash -n tests/e2e/lib.shto syntax-check the shell changeseslint src/types/featureFlag.ts, no issues