Design: Filter Vulnerability Report by Detected Date
Problem
Large or long-running projects can accrue a high number of vulnerability records over time. The Vulnerability Reports will look at all records when they load as their current scope is all vulnerability records. Loading the entire history of vulnerability records dramatically reduces performance and at times causes the report to encounter a loading error. This is even more problematic on the Group and Security Center reports as these load full history across multiple projects.
Proposal (updated)
Allow users to filter the Vulnerability Report by detected date range {last 30 days, last 60 days, etc}.
It is an open question what—if any—performance gain might be realized by choosing a limited default range (e.g. 30 days). We should first look to verify any likely change to page performance. Depending on the outcome, we may pursue one of two paths:
- Always default date selection of "All" (same as current behavior)
- Default to 30 days and remember each user's date range selection for each vulnerability report
With the first case, when users select another date range, the selection is reflected on the querystring like the other filters. Navigating to a vulnerability record and back using the browser controls will persist the filter selection. Filtered views are also directly shareable by copy the URL. However, visiting a vulnerability report by using the Security & Compliance menu entry will always default to date range to "All". This is the easiest to implement as we aren't persisting the user's selection locally. If we find little to no performance improvement, this is the simplest and preferred path forward.
If there is a significant performance gain, then it makes sense to chose a default of shorter duration (e.g. 30 days). Having a short timeframe view is not only a change to what users are accustomed to but may also be too restrictive for how they prefer to work. This means an extra click every vulnerability report view and can lead to frustration. To help alleviate this, we should investigate persisting this filter's selection locally for the user, per vulnerability report. The second case will be more complex and may not be pursued unless the results of the performance investigation are significant.
Original Proposal (click to expand)
The new default will be last 30 days.There is a slight risk that this more limited default view will cause confusion and be a slight inconvenience for users/teams used to seeing the full history. To account for this, the new detected date range filter should remember the last value selected per vulnerability report, per user. It is acceptable to use client-side storage such that a user's selections won't persist if they change browsers/computers.