Configuration screen for Secure features and enabled/disabled status
The UI is not explicit about the configuration requirements nor status for Secure features. The user’s day 1 experience and required configuration setup is confusing.
Users find it difficult to know which security scans are enabled or disabled.
Areas new user may navigate to on Day I:
- Security dashboard group
- Security dashboard project
- License compliance (management settings and https://gitlab.com/gitlab-org/gitlab-ee/issues/13582 )
- Dependency list
|License management||Group dashboard||Project dashboard|
|UI displays license management - In this case: the user could start adding licenses to blacklist/approve, even though the feature isn’t configured. (open issue: https://gitlab.com/gitlab-org/gitlab-ee/issues/12685)||The UI displayed in the group level states: “We’ve found no vulnerabilities for your group”, but it’s not explicit about what configuration has or has not been set up. Our user tests have shown most navigate to and end up on this page (when given the task to configure SAST)||Project level UI display|
- Introduce a new screen under
Security & Compliance, called
- On the new screen, display to users whether each of the various security scans is activated or disabled
- Link to relevant product documentation on how to manually enable/disable scanning
Leverage our documentation by displaying the most relevant configuration next steps and corresponding documentation (links) directly in the UI. Additionally, communicate configuration status/awareness needed for the feature to be activated.
|i. Information architecture||ii. UI (wireframe) configuration||iii. Already configured|
|Configuration accessible in left nav - user testing showed users went to this location to attempt to configure SAST &1784||UI displays info text, Secure features, and configuration status (all anchors seen link to documentation or "latest pipeline" to pipline page)||UI displays in the case that AutoDevOps has been configured|
- Use the word "configured" instead of "activated"
- Identity another term when not configured: could be "unconfigured", "not configured", or ?
- As a follow-up issue, we'd want to communicate to the user if a feature is supported or not. Example, instead of "not yet configured" the status would read "not supported" (languages)
- research issue %12.4 in-progress: ux-research#359
- dependency on #13662 completion
- configuration defined as: in the pipeline of the default branch, there's at least one job generating a particular kind of report. This is true as soon as the CI config has been parsed and evaluated, even if the pipeline is still pending. (mentioned by Fabien here: #13662 (comment 215607663))
- follow up issue: https://gitlab.com/gitlab-org/gitlab-ee/issues/13646
|i) MVC||ii) Dashboard, w/ 1+ scans configured||iii) User one-click configuration|
|System identifies that the project isn't configured to run security scans. The UI displays an awareness message to user. Links displayed to documentation for configuration requirements||Once 1 or more scans have been set up, visualize the scans that have been enabled in the dashboard. This serves user 1) awareness of what scans are providing data in the dashboard, 2) nudge to utilize other scans. Admin has the ability to remove the section “don’t show me this” (or removed after X days)||Displays configuration documentation links, with ability to add scan configuration script to the project’s
- Issue evolved to focus on configuration page showing configuration status. Will open separate issues to address day 1 UI on the dashboard, dependency list, and compliance list - similar to https://gitlab.com/gitlab-org/gitlab-ee/issues/12685