## Problem Currently, we are enabling the scoping feature in two steps(Details see [doc](https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html#security-policy-scopes)): * step1<span dir="">, the user needs</span> to link the group to the SPP to the projects/groups how users want to scope them * step2, the user needs to edit the policy scope But the user doesn't have to follow the order. If they do it in the wrong order, first scope and then link, or they might want to modify the existing scoped policies. It creates some confusing times in the following workflows: **In summary, the problem always happens when the `New scope settings` are different from `projects that are linked SPP`** #### Scenario * _Sub-group-policy-storage_ is the source for **Daily-scan-policy** * **Daily-scan-policy** is stored in _Sub-group-policy-storage-SPP_ * _Sub-group-product-1_ has two projects: * new-product-1 * new-product-2 * _Sub-group-product-2_ has two projects: * old-product-1 * old-product-2 * There is a compliance framework named :red_circle: framework-1 contains: * new-product-1 * old-product-1 <table> <tr> <th> </th> <th>Case 1</th> <th>Case 2</th> <th>Case 3</th> </tr> <tr> <td>Steps of user workflow</td> <td> 1. The user sets the scope of **the daily scan policy** with options: `all projects with compliance frameworks`: :red_circle: <span dir="">framework-</span>1 2. The **_Sub-group-policy-storage-SPP_** is not linked with **Sub-group-product-2** yet 3. User links **_Sub-group-policy-storage-SPP_** to **Sub-group-product-2** </td> <td> 1. The user sets the scope of **Daily-scan-policy** with options: `all projects in this group` 2. User links another subgroup **Sub-group-product-2** to **_Sub-group-policy-storage-SPP._** </td> <td> 1. User link **Sub-group-product-1** to **_Sub-group-policy-storage-SPP._** 2. The user scope with options: `specific project`: new-product-1 3. User links another subgroup **Sub-group-product-2** to **Sub-group-policy-storage-SPP** </td> </tr> <tr> <td>Problem</td> <td> 1. In step 2, the user might need to remember the linking part, and we don't warn them that they still need to link it. 2. after step 3, go to the project named **old-product-2**, the policy is still inherited, but **old-product-2** is not part of :red_circle: framework-1 **In other words, the scope settings are different from how the user sets them.** 3. after step 3, go to the project named **old-product-1** and go to the policy list. The scope of the **Daily-scan-Policy** is different from the SAME policy listed in **Sub-group-policy-storage** one says `all projects a compliance framework`, the other says `this project` **_In other words, 1 policy has two different scope_** </td> <td> 1. After step 2, check **Daily-scan-Policy** from **Sub-group-policy-storage;** the scope says `all projects in this group,` and go to **Daily-scan-Policy** on **Sub-group-product-2** it also says: `all projects in this group` is not clear 'This group' means which group; currently, it contains both 1. **Sub-group-policy-storage** 2. **Sub-group-product-2** 2. After step 2, check **Daily-scan-Policy** on **Sub-group-policy-storage;** the source says `this group,` and go to **Daily-scan-Policy** on **Sub-group-product-1**. It also `this group` . Isn't the Source should be only from one group? Logically, how can 1 policy have two sources? </td> <td> 1. After step 3, go to **Daily-scan-Policy** from **_Sub-group-policy-storage_** **,** it says `specific project: new-project-1`. But if you go to old-product-1 and check the **Daily-scan-Policy,** t says: `this project.` So it is against the scope of **Daily-scan-Policy** listed in **_Sub-group-policy-storage._** **_In other words, 1 policy has two different scope_** </td> </tr> </table> ## Solution ### MVC Fixed all the issues listed * https://gitlab.com/gitlab-org/gitlab/-/issues/452210+ can solve: Case2-Problem1 * [Bug: inherited policy scope should be consistent](https://gitlab.com/gitlab-org/gitlab/-/issues/452194 "Bug: inherited policy scope should be consistent") can fix Case1-Problem3 * [(Need design) Bug: if the linked project is not part of the group, it shouldn't be showing as inheritated](https://gitlab.com/gitlab-org/gitlab/-/issues/452205 "(Need design) Bug: if the linked project is not part of the group, it shouldn't be showing as inheritated") can fix: Case1-Problem2, Case3-Problem1 * https://gitlab.com/gitlab-org/gitlab/-/issues/452209+ can solve: Case2-Problem2 * [(Design needed) Show a list of Linked projects/subgroup/group](https://gitlab.com/gitlab-org/gitlab/-/issues/452371 "(Design needed) Show a list of Linked projects/subgroup/group") can solve can solve: Case1-Problem1 ### Ideal When users scope something that contains groups/projects that are not linked, we automatically link it for them. So they don't need to manually link it and create problems: when they **linked the groups/projects** and **scope settings** are different.