Design: MVC: Advanced filtering on the Vulnerability Report
Problems to solve
- No built-in search functionality. Customers want to search for something specific in the Vulnerability Report and currently have to go page by page and CTRL+F to look for particular keywords.
- There are several variables that users want to filter by (e.g. identifier, location, assignee, branch, SLA) that we don't offer with our current filters, and can't add because they're not scalable in the UI because of the limited horizontal space on the page. Wrapping to other lines may work, but a) it would push the primary content further down the page for some filters that aren't relevant to the user or to their particular task and b) searching among the many static filters for the right one would be time-consuming and may cause to cognitive overload.
- Excluding a particular value is cumbersome: the user has to select all items in the dropdown except for the one they want to exclude. This is an impossible workflow when considering some filters have an exponential number of items, such as identifier. We need
is
/is not
/ andis one of
functionality.
More details
This FigJam goes into more detail, but most importantly, we would need logical groupings of the identifier and value pairings (see first potential solution in table below). According to @markrian, explains at this part of this YouTube video that there is a multi-select option in GL-search, which would help with condensing the number of tokens. Even with this implementation, scalability (specifically, having to horizontal scroll to see all tokens) may still be a problem, hence the second potential solution in the table below, which would introduce a new kind of customized static filters. Update (10/10/2023): Neil says that we would most likely hit timeout issues before the user could add this number of tokens anyway.
Problem with filtered search component | Potential solutions |
---|---|
- We learned in Allow filtering vulnerability dashboard by non-remediated activity, there are some backend challenges when it comes to the performance or feasibility using GraphQL in implementing the filtered search component (the latter of which would require some expanding of it's current functionality). We could use the filtered search component without free text search, but not everyone on the team thinks this is worth implementing it with limited functionality. More in Spike: Investigate options for searching vulnerabilities.
Decoupling search from filtering gives us more technical flexibility. Global search only works if you have elastic search enabled and your instance is hooked up to it. (And considering that it's an extra piece of infrastructure that will have to be managed and may incur extra costs, so not all users will want to do that.)
- @aregnery Also makes a case for separating out search from filtering in GL-search throughout https://youtu.be/FgJBT7iX_6w
- Our filters on the Vulnerability Report page require a combination of
and
andor
functionality, in addition tois
andis not
. This is something we should try to address in a redesign.
Related issues & considerations
- What should be the relationship between filters, sort by, and grouping?
Design: Customizable views for triage and monitoring looks into filtering and other customization on the Vulnerability Report while Design: Vulnerability groups looks into grouping (which will have to be considered in parallel with sorting functionality).
A query language and/or more advanced filtering/sorting/searching is an absolutely necessity for the future of GitLab and is high up on our list of things we want to work on as soon as we're able.
This issue should be used to discuss ideas around more flexible filtering on the Vulnerability Report specifically so we can keep Allow filtering vulnerability dashboard by non-remediated activity scoped to an MVC solution for adding filters.
- There have been multiple requests to enhance the functionality of the filtered search component, but it seems like as of May 2022, there aren't the resources available or isn't considered a high enough priority to use current resources on. These requests can be found in the Filter Bar enhancements epic and the
not
andor
in search and filter bars, including saved config in boards epic (both owned by devopsplan). - More pain points in Issue filter bar is extremely frustrating to us... (#371048)
Questions
- Can we use the multi-select option in the GL-search? Is there a reason other pages aren't already currently using this?
- Would users want to add so many filter tokens to the filtered search component that the limited space would become a problem (hiding filter tokens)?
- Would it be easier from a FE and BE perspective to build out new filters or to customize GL-search so it meets our needs for this page?
May 25, 2022 Update: I recorded this video to cover outstanding questions and concerns: https://gitlab.zoom.us/rec/share/qaWeLtCc_9SAZrYT0w8PDPEPqgFV-7vvg5cR10eqtP-f7am7Qz_46VhrjakhMkDx.sh2NJP7ooiaEbijX?startTime=1653502888000
Proposal
Either
- Bring the filtered search component (filtered-search) over to the Vulnerability Report, but only if we can implement multi-select and the is/ is not one of/ is one of operator.
or
- Develop a custom filtering experience.
Component | Problem | Solution |
---|---|---|
Filtered search component | Limited horizontal space before filters are hidden | Multi-select will help with this a bit, but horizontal scroll is the only solution, as multi-line won't work. In the filtered search component, the identifier will most likely have to be shown at all times, whereas what I tested with my custom filter pattern, exposing the identifier at all times isn't required (which saves on horizontal space). |
Multi-select doesn't join values with the same identifier | added values must be grouped in with the existing identifier and subsequent values, if one already exists | |
Probably won't be able to launch component with search functionality, even though this expectation is set with this component in other product areas | With the custom filters I designed, there’s no expectation of search and we could add a separate search box when we’re ready (when the backend is ready to support this)) | |
Custom token pattern | Doesn't align with anywhere else in the product | Change others to this pattern? Maybe create rules where one is used in some cases and this one is used in others? |
No teams (to my knowledge) are currently working on usability improvements to the filtered search component | Implementing the filtered search component here would provide usability improvements for our part of the UI and others could benefit | |
More dev LOE? | Needs validation by engineering - building a custom pattern may or may not be a higher LOE than improving the existing component |
Persona
Business objective:
- Increase user satisfaction with Vulnerability Management features
- Increase adoption of Ultimate by improving the Vulnerability Report experience (only available to Ultimate customers)
- Develop and share components in order to improve customization and usability on all tables across GitLab product
Proposal
Switch from the static filters to the filtered search component. See MVC requirements below and designs in the design section for more info.
Requirements (also success criteria)
MVC
- User needs to be able to filter their vulnerabilities by more variables than are currently offered (for MVC this means adding
Identifier
), and in a scalable way so that more filters can be added later on without breaking anything. - User needs to be able to easily change (edit, add, remove) any variable within the filters set whenever they start a new task, without being forced into removing them all and starting over. Clicking on the value in the token should open the popover and show the selections in the dropdown. The user should easily be able to change the operator or the values without removing and starting over.
- User needs to be able to delineate filtering from searching, and the user experience needs to be predictable and not confusing for either.
- User needs to be able to apply multi-select filters where the values are grouped with other values matching the identifier, even if added separately or other identifiers are in between.
- When a filter is applied and 3 or more variables have been selected, the filter should truncate past the 2nd variable. For example,
Critical, High, + 2 more
. NOTCritical, High, Medium, Low
. We can consider truncating after 1 added value if it's longer, e.g. a long identifier name. - User needs to be able to click on the token and see the selected values at the top of the dropdown for some filter types (
Identifier
,Project
), so they don't have to scroll through hundreds or thousands of values to find the selected items. - User needs the component to be largely free from significant and long-standing bugs that limit utility and negatively impact usability.
Post-MVC ideas
Design: Post-MVC: Advanced filtering & search o... (#431805)
- User needs to be able to find a vulnerability with a custom string (raw text search), so they can find something they're looking for if it's not available as a filter, at least at the project level.
- Vertical scrolling (instead of horizontal)
- Our team needs to be able to gather data analytics on which filters customers are applying and how many, so we can see whether it's worth looking into the UX of vertical scrolling and scalability.
Known technical constraints
The reason we haven't been able to add this functionality so far, and something we'll have to address on the backend moving forward, is the technical challenge that complex filtering capabilities will have with the number of vulnerabilities that we have to work with. Even with the filtering options that we have today, we're starting to hit the limits of what Postgres is able to do. The team has been looking at alternative options for searching ( #352665 (comment 1243987880)) that we can implement in order to start providing these sort of features, but we're still trying to establish a foundation that we can use to start building those features.
From @ghavenga (on 2023-11-08):
Ultimately, for the quantity of data that we're dealing with already, I'm pretty sure that we would have to partition our vulnerability data before any search capabilities can be considered even slightly feasible. When I did the investigation, without partitioning, searching even a single field on a significant project was an exercise in optimism. On the bright side, if we correctly implement the partitioning, we would see a wide range of performance benefits, as queries should generally perform better due to the DB's ability to have a worker per partition table. Write speeds also benefit for the same reason as the various table maintenance functions Postgres runs implicitly are able to run in parallel across partitions. All in all, the search functionality I investigated should enable searching across all text columns reasonably well, and would cover the fuzzy search situation for
CVE-2018
implicitly because with the lexeme indexing it does, that would dissolve any of those variations into the lexeme's CVE and 2018 . This does come at the price that there is not a specific search (if you only wantCVE-2018
, you're going to get the other variants). TL:DR: It's possible, but not a small development effort. Implementation would likely take at least 2-4 milestones.
That said, the Large Namespaces problem has only grown since I did that research, which is a bigger performance problem not included in that. If the primary desire is for group level search, then we'd probably need to allocate development effort to help #g_database improve the large namespace problem before even worrying about text search, since we're already having to limit basic filtering features for the largest namespaces.
Group report queries are ultimately the same as project level, but with a far greater quantity of data and with the additional cost of needing to resolve that data across the entire namespace hierarchy. Iteratively speaking, it'd be possible to deliver value sooner by only focusing on the project level report first, but from the testing I did, we'll need to do the partitioning and data modifications to make even project level search feasible.