<!-- 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 While working on https://gitlab.com/groups/gitlab-org/-/epics/5510+ we identified that the count of projects we show for a security policy that is linked to a compliance framework is not the exact count. Currently we show the count of all projects in the root-level group that has the compliance framework linked, but if the policy is linked to a sub-group, we need to show the count of projects within the sub-group rather than the root group. As a part of this issue, we want to introduce a graphql API to return the count of projects that are associated with the scope (`policy_scope`) of the policy. ## Relevant links - Related discussion: https://gitlab.com/gitlab-org/gitlab/-/issues/432513#note_1843748027 ## 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 - [ ] gitlab~3412464 Step 1 - [ ] gitlab~3412464 Step 2 - MR 2: Part 2 - [ ] gitlab~2492649 Step 1 - [ ] gitlab~2492649 Step 2 - MR 3: Part 3 - [ ] gitlab~3412464 Step 1 - [ ] gitlab~3412464 Step 2 --> <!-- Workflow and other relevant labels # ~"group::" ~"Category:" gitlab~3207279 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 gitlab~11090870 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! -->