When a user filters the list on the security dashboard and then navigates to a vulnerability to take any action; when they return to the dashboard the filters are reset. This negatively impacts the experience in a significant way.
Solution
Match the experience on the issue list or todo's list. When a user returns to the dashboard from a vulnerability, their filters should persist.
Judging by the experience in the issue list, when a user clicks on a navigation item, the filters are reset. When the user navigates back to the list from a list items detail page, the filters are persisted.
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related or that one is blocking others.
Learn more.
Heads-up on this. This may cause significant frustration with users. We never encountered this before because we were using models and never had to handle a "navigate back experience". This was an oversight on my part.
@andyvolpe I agree; I didn't consider this, either, but have already experienced the inconvenience while using the dashboard on .com. In addition to loss of efficiency, it will also help explain why we removed the "Hide Dismissed" toggle as I've heard that question come up internally a few times already.
@lkerr I'm pulling this into %13.1, please see if we can get an FE weight on it.
@matt_wilson Agreed, had a quick think about the dismiss toggle and believe it was ultimately the right call given that now the toggle would interact oddly with the new state field. I would imagine, today, if the user toggles hide dismissed, we would select (detected, resolved, confirmed) which still might not be the true need for the user. I think there is an issue for this topic. searching...
We're reusing the same component - so a fix should apply to all three dashboards. Therefore I think one issue should be enough.
I can confirm there is no backend work required. We'll use the URL to persist the filters and keep a consistent navigation experience.
We need to serialise data and append it to the URL when a filter changes and on component mount we need to parse the URL as source of truth. When a filter changes, we need to keep the URL in sync. I believe assigning this a 2 wouldn't be inappropriate.
For more information; The filters are broken because they rely on the router and 390c008c cleans the router as part of another issue. @samdbeckham we still need the router, I am going to re-add it. Can you see foresee any potential risk for doing that?
The tests are passing even when the router is removed. This is because we're mocking the properties we pass to the components. I am going to create a follow up issue for testing the *_init.js files.
@dcouture Was it ever working for you? I just tried it (https://gitlab.com/gitlab-org/gitlab/-/security/dashboard/) and it did work. One thing to be aware of is the filters "persist" like many of the other "list" filters like the Issue List. That is to say they do not persist universally as you navigate around the application. They mainly work if clicking into a specific vulnerability and then navigating back. You'll note that the filters are URL parameter-based so you can even move forward and back through progressions of changing the filters. You could also share a pre-filters list view.
And because of this "light persistence", the filters will also not be maintained across projects. Setting filter defaults per project or having user-specified persistence/defaults would be good improvements for the future.
Ah I see it works when I use "back" but not when I go back to the dashboard using any other way. I thought it was supposed to persist across different visits to the dashboard. Thanks for clearing that up @matt_wilson
If it can allow quicker iteration, I'd personally be totally fine with a default view that excludes Dismissed and Resolved vulnerabilities without any user settings to modify defaults. Given the large amount of false positives, the dashboards are flooded with Dismissed results and we pretty much never want to see them. Resolved issues don't create as much noise but we also rarely want to see those. I feel like hiding them behind an extra click would make more UX sense than showing everything by default.
@dcouture Yes, sorry about the misleading use of "persistence". It's an MVC?
The good news is we're already looking to address in %13.3 the challenge posed by showing Dismissed (and Resolved) by default: #217472 (closed)
In the near future, as we redo the vulnerability lists at all levels, the default view will just be new/detected vulnerabilities with a quick tabbed system to drill in to other statuses as needed: #222448[b01_project-dashboard.png]