The project Security Dashboard and pipeline Security Dashboard display the same empty state as the group Security Dashboard, with group-specific wording, which is not ideal.
This is because the empty state is hard-coded in the security-dashboard-table component, and was originally intended only for use in the context of a group.
The most obvious way to fix this would be to expose a slot (perhaps called empty) in the security-dashboard-app component.
This will also have implications for the eventual use of the dashboard in the MR widget, and the instance-level security dashboard.
Proposal
Instance dashboard
Group dashboard
Project dashboard
Pipeline
Dashboard
Title
Text
Link
Instance Security Dashboard
No vulnerabilities found for this instance
While it's rare to have no vulnerabilities for your instance, it can happen. In any event, we ask that you double check your settings to make sure you've set up your dashboard correctly.
No docs yet?
Group Security Dashboard
No vulnerabilities found for this group
While it's rare to have no vulnerabilities for your group, it can happen. In any event, we ask that you double check your settings to make sure you've set up your dashboard correctly.
While it's rare to have no vulnerabilities for your project, it can happen. In any event, we ask that you double check your settings to make sure you've set up your dashboard correctly.
While it's rare to have no vulnerabilities for your pipeline, it can happen. In any event, we ask that you double check your settings to make sure all security scanning jobs have passed successfully.
@andyvolpe, would you provide appropriate copy for the empty state of the project and pipeline dashboards, please? Also, can the empty state SVG be re-used for all security dashboards?
Can we disable the security tab in the pipelines page when there are no vulnerabilities?
The security tab itself is linkable, so we'd need to rework the backend controller to redirect in the case there are no vulnerabilities. That's probably not the right approach, since it'd mean two queries would need to be run each time the route is accessed: once by the backend to check whether a redirect is necessary, and again by the frontend to actually get the data to display.
Given the Project Security Dashboard also already shows the wrong empty state, I think addressing this issue is the right way to go.
@twoodham / @andyvolpe: I am tentatively setting %12.4, this seems to be a small one, which becomes more important the more Dashboards we have.
I have added an table to the description with the proposed wording for each dashboard, maybe you can have a second Look @andyvolpe and propose something for the Instance and Pipelines Security Dashboards?
Title: "We've found no vulnerabilities for this pipeline"
Text: "While it's rare to have no vulnerabilities for your pipeline, it can happen. In any event, we ask that you please double check your settings to make sure all security scanning jobs have passed successfully."
"While it's rare to have no vulnerabilities, it can happen. In any event, we ask that you please double check your settings to make sure you've set up your instance dashboard correctly."
@axil Mind taking a look. Not in love with the last statement because the user needs to ensure all projects that they have added are set-up correctly.
Maybe something like:
"While it's rare to have no vulnerabilities, it can happen. In any event, we ask that you please double check your settings to make sure you've configured the projects you want to track correctly."
"While it's rare to have no vulnerabilities, it can happen. In any event, you may want to double check your settings to make sure you've configured the projects you want to track correctly."
And change the rest of the text accordingly.
Another note, is this a good experience? How would I know if the dashboard is empty because of a misconfiguration or because there are no vulnerabilities? It's like Schrödinger's cat
Another note, is this a good experience? How would I know if the dashboard is empty because of a misconfiguration or because there are no vulnerabilities? It's like Schrödinger's cat
Good question, @axil! To paraphrase something Sam said to me about this once, we're telling the user that either they've done a great and flawless job (no vulnerabilities! ), or they've really messed it up (misconfigured job ).
@axil@markrian@samdbeckham I've updated the text to reflect the recommendations by @axil and will consider this ~"UX ready" if we are in agreement with what is in the description.
We should definitely open up another issue (if there isn't one already) to discuss how to handle these cases:
config and permission error might be able to be grouped together in one empty state and likewise we can also consider approaches that handle these events not only with empty states but with alerts or another component that would create a better experience in the long run.
Maybe an approach to this would be a ~"product discovery" where Engineering and UX and Tech writing can team up once and for all to get this nailed down?
Aha! Just in time. I've added all the FE for this now in !18382 (merged) Once this is ~"UX ready" I'll update all the strings.
Should I be using the old illustration or swap it for the permissions one? We're still in that weird state where it may or may not be a configuration error.
Not yet, unfortunately. That's a couple of iterations away I reckon. I'll stick with the old one for now and get those strings updated.
Quick note on the action button color though. It's currently green and is for all the empty states using the empty state component. Should it universally be blue instead? Design specs show them as green too, but I agree, they should probably be blue. It's a simple change, but it should be a global one done in GitLab UI and the design system.
Just a thought, if there are no vulnerabilities found on a pipeline, we don't show the security tab anyway right? So maybe an empty state isn't required here.
I'm basing this on a semi-assumption here. Maybe @markrian can tell me if this is correct or not.
Unless it's the case that no found vulnerabilities results in no report artifact (which would be weird, and I'd be surprised by), it looks like pipelines dashboard needs an empty state as well, I'm afraid!
Hmmm, that seems pretty weird to me. I think you're right though. I'll add the empty state in as it's a boring solution and a fallback. But we should probably change the logic to only show the security tab if there are vulnerabilities, rather than potentially empty report artifacts. I'll open a separate issue for that though.
Actually, I've just thought, we can filter the vulnerabilities on the pipeline too. So you can filter it to the point of 0 vulnerabilities and an empty state would be required at that point too.
Worth looping UX into that issue. Someone may have set up security scanners, and wonder why the Security tab isn't visible. I think we'd probably want to explicitly say that no vulnerabilities were found
@leipert It looks like we're going to miss the review deadline for this one and it may slip into %12.5 It's all done in !18382 (merged) but we're still waiting on final confirmation on what these empty states need to say
@samdbeckham updated text and provided mocks for each of the states defined in the description. Marking as ~"UX ready" Let me know if you have any questions