Add disabled state and tooltip to tool filter
What does this MR do and why?
This MR adds a disabled state and tooltip to the tool filter component.
Screenshots or screen recordings
Disabled State | Tooltip |
---|---|
![]() |
![]() |
Note: once this MR has been merged > !106240 (merged), the tooltip will appear on the side instead of the top
How to set up and validate locally
- Enable the FF
echo "Feature.enable(:refactor_vulnerability_tool_filter)" | rails c
- Instance view (Menu > Security > Vulnerability Report)
- Group view (Group > Security & Compliance > Vulnerability report)
- The tool filter dropdown will have a disabled state (if applicable) and a tooltip when hovered
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Related to #383294 (closed)
Merge request reports
Activity
changed milestone to %15.7
assigned to @sming-gitlab
1 Warning featureaddition and featureenhancement merge requests normally have a documentation change. Consider adding a documentation update or confirming the documentation plan with the Technical Writer counterpart.
For more information, see:
- The Handbook page on merge request types.
- The definition of done documentation.
1 Message CHANGELOG missing: If you want to create a changelog entry for GitLab FOSS, add the
Changelog
trailer to the commit message you want to add to the changelog.If you want to create a changelog entry for GitLab EE, also add the
EE: true
trailer to your commit message.If this merge request doesn't need a CHANGELOG entry, feel free to ignore this message.
Reviewer roulette
Changes that require review have been detected!
Please refer to the table below for assigning reviewers and maintainers suggested by Danger in the specified category:
Category Reviewer Maintainer frontend Stanislav Lashmanov (
@slashmanov
) (UTC+4, 3 hours ahead of@sming-gitlab
)Jose Ivan Vargas (
@jivanvl
) (UTC-6, 7 hours behind@sming-gitlab
)To spread load more evenly across eligible reviewers, Danger has picked a candidate for each review slot, based on their timezone. Feel free to override these selections if you think someone else would be better-suited or use the GitLab Review Workload Dashboard to find other available reviewers.
To read more on how to use the reviewer roulette, please take a look at the Engineering workflow and code review guidelines. Please consider assigning a reviewer or maintainer who is a domain expert in the area of the merge request.
Once you've decided who will review this merge request, assign them as a reviewer! Danger does not automatically notify them for you.
If needed, you can retry the
danger-review
job that generated this comment.Generated by
DangerBundle size analysis [beta]
This compares changes in bundle size for entry points between the commits 6031ddba and b5740adf
Special assetsEntrypoint / Name Size before Size after Diff Diff in percent average 3.45 MB 3.45 MB - -0.0 % mainChunk 1.86 MB 1.86 MB - 0.0 % Significant Reduction: 3Expand
Entrypoint / Name Size before Size after Diff Diff in percent pages.projects.settings.merge_requests 2.19 MB 2.14 MB -52.11 KB -2.3 % pages.projects.settings.repository.create_deploy_token 1.39 MB 1.33 MB -51.32 KB -3.6 % pages.projects.settings.repository.show 1.39 MB 1.33 MB -51.32 KB -3.6 %
Note: We do not have exact data for 6031ddba. So we have used data from: f257619d.
The target commit was too new, so we used the latest commit from master we have info on.
It might help to rerun thebundle-size-review
job
This might mean that you have a few false positives in this report. If something unrelated to your code changes is reported, you can check this comparison in order to see if they caused this change.Please look at the full report for more details
Read more about how this report works.
Generated by
Dangeradded 1 commit
- b5740adf - Add disabled state and tooltip to tool filter
Allure report
allure-report-publisher
generated test report!e2e-review-qa:
test report for b5740adfexpand test summary
+-----------------------------------------------------------------------------------------+ | suites summary | +------------------------------------+--------+--------+---------+-------+-------+--------+ | | passed | failed | skipped | flaky | total | result | +------------------------------------+--------+--------+---------+-------+-------+--------+ | Verify | 12 | 0 | 1 | 0 | 13 | ✅ | | Create | 28 | 0 | 1 | 0 | 29 | ✅ | | Plan | 49 | 0 | 1 | 0 | 50 | ✅ | | Govern | 13 | 0 | 5 | 1 | 18 | ❗ | | Manage | 39 | 0 | 4 | 2 | 43 | ❗ | | Feature flag handler sanity checks | 9 | 0 | 0 | 0 | 9 | ✅ | | Package | 0 | 0 | 1 | 0 | 1 | ➖ | | Version sanity check | 0 | 0 | 1 | 0 | 1 | ➖ | | Configure | 0 | 0 | 1 | 0 | 1 | ➖ | +------------------------------------+--------+--------+---------+-------+-------+--------+ | Total | 150 | 0 | 15 | 3 | 165 | ❗ | +------------------------------------+--------+--------+---------+-------+-------+--------+
requested review from @dftian
- Resolved by Samantha Ming
@dftian woohoo, so this is the last MR for this epic! Do you mind giving this a review?
@beckalippert I wanted to get UX feedback on this one. In another MR in
gitlab-ui
, I was specifically asked to change the disabled text color for a dropdown item to a darker gray than what I had originally: gitlab-ui!3182 (merged) However, now that we're actually using it, I find that it's too hard to visually distinguish between the disabled and non-disabled items:Here, only
SAST
andAll tools
are enabled, but I find that it's very hard to tell unless you're really looking for it. I was wondering:-
Should we make the text color lighter? If so, should this be a
gitlab-ui
change, or something specific to our filter dropdowns? -
Should we add something else to make it more obvious an item is disabled, for example an icon?
-
@dftian So to be clear, we're disabling items when there are no results (vulns, in this case) available? I'm not sure we need to be disabling if there are no results; we can rely on the empty state, no?
Edited by Becka LippertI'm not sure we need to be disabling if there are no results
@beckalippert sorry, do you mind elaborating on this? From our discussion > option 2a, when there are unavailable report types (meaning there are no vulnerabilities for that report type), that filter option would have a disabled state (unselectable, gray text, and a "Not available" tooltip). Hopefully, that was your understanding too
So what Daniel is proposing here is perhaps we can lighten the text for the unavailable options, so it's more distinguishable from the available options. Ex.
Current Proposal gl-text-gray-600
Perhaps? gl-text-gray-300
Btw, I'm just waiting for my MR to get deployed. So you can see what is currently happening and make a more informed decision then. I will ping you when it's ready
Re-thinking this, maybe it's okay for the current gray text (probably done so because of accessibility).
Once this issue is completed > #383297 (closed), which adds a
n/a
icon badge, the distinction would be a lot more clear :thumbs-up:I'd recommend we wait until the badge issue is completed, then play it by ear, iterate and improve if needed
@sming-gitlab @dftian Right, thanks for reminding me this is an iteration towards the badges! I agree we probably don't have to update the colors right now because badges are right around the corner
- Resolved by David Pisek
@dftian
, thanks for approving this merge request.This is the first time the merge request is approved. To ensure full test coverage, a new pipeline will be started shortly.
For more info, please refer to the following links:
mentioned in issue #385029 (closed)
enabled an automatic merge when the pipeline for c7bfe679 succeeds
mentioned in commit 5365ee9d
added workflowstaging-canary label and removed workflowin dev label
added workflowcanary label and removed workflowstaging-canary label
added workflowstaging label and removed workflowcanary label
added workflowproduction label and removed workflowstaging label
mentioned in merge request !106382 (merged)
mentioned in epic &9301 (closed)
added releasedcandidate label
added releasedpublished label and removed releasedcandidate label
mentioned in issue #428133 (closed)