Design: Customizable saved views
Release notes
Problem to solve
Users require the ability to view different data depending on what their task is; prioritization, triage, tracking, resolution, etc. We should explore solutions that allow for flexibility and customizability of the report data, beyond filtering to provide users with saved views they can add/remove and manage.
We will be achieving further flexibility of viewing options on the Vulnerability Report in Design: Vulnerability groups.
Intended users
User experience goal
- Now: Users can create custom report views with saved filters, columns, and sort defaults, possibly also arrange the order of tabs
- Later: Users can take the parameters used to create the custom view and turn them into an exportable report
User stories
-
As a security engineer, I need customizable saved views so that I can...
... keep an eye on specific identifiers that I want to follow closely.
... have a view that's the same as the current default but with Still Detected filter applied (which I strongly believe should be the default value).
... figure out what needs to be updated and where for specific namespaces, CVEs, and OS versions for container scanners.
... have easy access to triaging issues per scan type, with the
still detectedanddoes not have issueactivity filters applied. For instance, reviewing Fedramp only vulns identified from container scanner. -
In general, customizable saved views helps save security engineers time from changing multiple filters to the same set of filters every day.
Requirements
- Create a new saved view
- Delete an existing saved view
- Allow affordance for longer titles and being able to view the entire title in some way.
- For example, we shouldn't truncate too much without at least adding a tooltip that shows the entire saved view name on hover. Some examples of what security engineers said they would want to name these views as:
- Sec Engineer 1:
Package Hunter Findings,SAST Custom Rule Findings,Leaked GitLab Tokens - Sec Engineer 2:
DAST new findings without issues,DAST new findings,CS new findings,Project X CS new findings
- Sec Engineer 1:
- For example, we shouldn't truncate too much without at least adding a tooltip that shows the entire saved view name on hover. Some examples of what security engineers said they would want to name these views as:
- Set created view as default
Potential requirements (need validation)
- Update an existing saved view
- Rearrange order of saved views
- Save and share as template for team members
- Save sorting. On the Dependency List, sorting is an external button, so would be easier to save as part of saved views. However, on the Vulnerability Report, the sorting is set in the column header - should this be replaced with a button?
Proposal
See design section below
Further details
When moving between tabs, the selected tab should refresh its content each time. This will ensure you always have an accurate view. The behavior is the same as when moving between the Overview, Commits, Pipelines, and Changes tabs in MRs.
On the Group Vulnerability Report, the behavior will be the same with the addition of the ability to pre-select specific projects to display in a saved view.
Permissions and Security
Documentation
Availability & Testing
What does success look like, and how can we measure that?
What is the type of buyer?
Is this a cross-stage feature?
Links / references
This was a highly liked feature in the Kano analysis, see ux-research#1295 (closed)
Outstanding questions
- Should this be settable at a group level and enforceable to the org (sub-groups)?
- Should we consider whether this should be set at a project-wide level (inherited by all in the project) or at a user-level? Should permissions or roles come into play here when it comes to who creates these custom views?
Steps
-
Design explorations -
Solution validation | Participant list & notes -
Design updates, if needed -
Solution validation round 2, if needed -
Share research results -
Design handoff