Disable identifier filter when group has more than 20k vulnerabilities

The following discussion from !179363 (merged) should be addressed:

• @svedova started a discussion: (+1 comment)

  FYI, if the group has more than 20k this feature won't work. Right now the behaviour is that the autocomplete won't work and GraphQL will return an error.

  I suggest disabling this filter (grey it out) with a popover that clarifies why it's disabled. @wandering_person how hard it is to inject the total amount of variables on the page load for a given/project?

changed title from Follow-up from "Enable identifier filter for group level" to Disable identifier filter when group has more than 20k vulnerabilities

/cc @dagron1 @wandering_person

@svedova are you thinking the same UI we have on groups with over 600 sub-groups:

@wandering_person yes, but just for the identifier filter. Other filters are still supported we're not disabling the whole filtered search all together.

Yes, such a comment makes sense:

"This report exceeds 20,000 vulnerabilities, and therefore the Identifier filter is not available"

@svedova @rlehmann1 WDYT?

@dagron1 yeah something like that. I'll get help from Technical Writing when developing the feature

changed milestone to %17.9

added backend devopssecurity risk management frontend groupsecurity insights missed:17.8 sectionsec typefeature workflowin review labels

removed workflowin review label

removed missed:17.8 label

added workflowrefinement label

assigned to @svedova and @wandering_person

added #517925 (closed) as child task

added #517926 as child task

FYI @wandering_person I created two tasks under this issue - one is for the backend and the other is for the frontend.

@svedova @wandering_person I added this to our 17.11 plan. Security Insight 17.11 Planning Issue (#521645).

backend Feature flag #520703 (closed) is enabled globally on gitlab.com (internal slack). Should we control via separate frontend feature flag?

documentation will be handled within the frontend task.

Should we control via separate frontend feature flag?

@nmccorrison Yes, if the frontend work requires a FF, we should make a new one. The backend flag is a derisk flag. The change involved adding an additional db query in the hot-path for all vulnerability-related graphql queries. The FF was there in case this additional query resulted in a noticiable performance regression.

Everything seems fine, so I will be putting up an MR soon to remove the flag

changed milestone to %17.10

mentioned in commit 79d13397

added featureenhancement workflowin review labels and removed workflowrefinement label

set weight to 2

added gitlab-org#13340 as parent epic

marked the checklist item @svedova started a discussion: (+1 comment) as completed

added workflowready for development label and removed workflowin review label

mentioned in merge request !180973 (merged)

mentioned in commit 1372b61e

mentioned in commit a4b73201

removed weight of 2

mentioned in merge request gitlab-com/www-gitlab-com!138191 (merged)

mentioned in commit a08f190e

added #520703 (closed) as child task

mentioned in commit 5672df16

mentioned in commit 6e539f4f

mentioned in commit a80705e6

mentioned in commit d7fd4b49

mentioned in commit 25c63f37

mentioned in commit 049e2e4a

mentioned in commit 0b2c4f40

mentioned in commit 592efe34

mentioned in commit 2489d7d4

changed milestone to %17.11

added missed:17.10 label

mentioned in issue #521645

added Deliverable label

changed health status to on track

added missed-deliverable label

mentioned in commit 1c83df01

mentioned in commit e9a99bc2

mentioned in merge request !184617 (merged)

Setting health status to needs attention as this item slipped the previous milestone.

Issue participants are welcome to override this by setting the health status to another value.