<!-- Implementation issues are used break-up a large piece of work into small, discrete tasks that can move independently through the build workflow steps. They're typically used to populate a Feature Epic. Once created, an implementation issue is usually refined in order to populate and review the implementation plan and weight. Example workflow: https://about.gitlab.com/handbook/engineering/development/threat-management/planning/diagram.html#plan --> ## Why are we doing this work <!-- A brief explanation of the why, not the what or how. Assume the reader doesn't know the background and won't have time to dig-up information from comment threads. --> While working on https://gitlab.com/gitlab-org/gitlab/-/issues/414895+ and refactoring specs, I noticed with the help of @bwill that the shared test `it_behaves_like "a working graphql query"` isn't doing anything: ``` Query.vulnerability(id) # order random query all fields for a sast vulnerability behaves like a working graphql query XXXXXX {"vulnerability"=>nil} ``` This is because the user is lacking permissions to read the vulnerability. The GraphQL returns a valid response, but doesn't actually tests any of the fields. If you fix the permission issue with: ```ruby let_it_be(:current_user) { create(:user).tap { |user| project.add_developer(user) } } ``` then you get a different error: ``` 1) Query.vulnerability(id) query all fields for a sast vulnerability behaves like a working graphql query returns a successful response Failure/Error: expect(graphql_errors).to be_nil expected: nil got: [{"message"=>"Cannot return null for non-nullable field Vulnerability.links"}] ``` ## Relevant links <!-- Information that the developer might need to refer to when implementing the issue. - [Design Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/<id>) - [Design 1](https://gitlab.com/gitlab-org/gitlab/-/issues/<id>/designs/<image>.png) - [Design 2](https://gitlab.com/gitlab-org/gitlab/-/issues/<id>/designs/<image>.png) - [Similar implementation](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/<id>) --> ## Non-functional requirements <!-- Add details for required items and delete others. --> - [ ] Documentation: - [ ] Feature flag: - [ ] Performance: - [ ] Testing: ## Implementation plan <!-- Steps and the parts of the code that will need to get updated. The plan can also call-out responsibilities for other team members or teams and can be split into smaller MRs to simplify the code review process. e.g.: - MR 1: Part 1 - [ ] ~frontend Step 1 - [ ] ~frontend Step 2 - MR 2: Part 2 - [ ] ~backend Step 1 - [ ] ~backend Step 2 - MR 3: Part 3 - [ ] ~frontend Step 1 - [ ] ~frontend Step 2 --> - [ ] Use the same `:current_user` for all scopes - [ ] Fix the fixture so the returned vulnerability has valid links data <!-- Workflow and other relevant labels # ~"group::" ~"Category:" ~"GitLab Ultimate" Other settings you might want to include when creating the issue. # /assign @ # /epic & --> ## Verification steps <!-- Add verification steps to help GitLab team members test the implementation. This is particularly useful during the MR review and the ~"workflow::verification" step. You may not know exactly what the verification steps should be during issue refinement, so you can always come back later to add them. 1. Check-out the corresponding branch 1. ... 1. Profit! -->