<!--- Please read this! Before opening a new issue, make sure to search for keywords in the issues filtered by the "regression" or "bug" label: - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=regression - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=bug and verify the issue you're about to submit isn't a duplicate. ---> ### Summary Members who have been granted access to a subgroup via group share from another subgroup are unable to see newly created projects. Please note that there is a separate issue related to group visibility that is captured in https://gitlab.com/gitlab-org/gitlab/-/issues/224771. ### Steps to reproduce I've reproduced this in two different group structures. #### Scenario 1 1. Set up a group, subgroup, and project structure like the following. ```mermaid graph TD; A[Group]-->B[Subgroup 1 - Projects]; B-->C[Projects]; A-->D[Subgroup 2 - Users]; ``` 2. Invite a user to `Subgroup 2 - Users` as a `Maintainer`. 3. [Share](https://docs.gitlab.com/ee/user/group/#sharing-a-group-with-another-group-core-only) `Subgroup 2 - Users` with Subgroup 1 - Projects and select `Maintainer` as the access level. 4. Observe that the added user can see the project that was just created in `Subgroup 1 - Projects`. 5. Create another project in `Subgroup 1 - Projects`. 6. Observe that the added user cannot see the project that was created after `Subgroup 2 - Users` was shared with `Subgroup 1 - Projects` and may or may not be able to access it even if they are told the project path of the new project. #### Scenario 2 1. Set up a group, subgroup, and project structure like the following. ```mermaid graph TD; A[Group]-->B[Subgroup 1]; B-->C[Subgroup 2 - Users]; B-->D[Project]; ``` 2. Invite a user to `Subgroup 2 - Users` as a `Maintainer`. 3. Share access to `Subgroup 2 - Users` with `Subgroup 1` with `Maintainer` level access. 4. Observe that the user can see the project that was already within `Subgroup 1` but will not be able to see or access any further projects or subgroups created within `Subgroup 1`. ### Example Setup - [Top-level group](https://gitlab.com/148890) - [Subgroup (for projects)](https://gitlab.com/148890/subgroup) - [Subgroup (for users only)](https://gitlab.com/148890/subgroup-maintainer) ### What is the current *bug* behavior? Users who are given access to a subgroup via a share from another subgroup are unable to see projects created in that subgroup after the sharing has been enabled. ### What is the expected *correct* behavior? Users given access to a subgroup via sharing with another subgroup should be able to see all projects in that subgroup, regardless of their creation date. ### Workaround There are two ways to work around this. 1. Remove and re-add the user to `C`. 1. Toggle the access level of the user in `C` to `Owner` and then back to `Maintainer`. ### Relevant logs and/or screenshots Member section of `B`:  Project list for `B` showing project's 1-6 that were created before sharing was enabled and `project-7` that was created after sharing was enabled, from the perspective of an `Owner`:  Project list for `B` showing that `project-7` is missing, from the perspective of the `Maintainer` of `C`:  ### Output of checks This bug happens on GitLab.com: `12.9.0-pre 7d593d238f4` ZD: https://gitlab.zendesk.com/agent/tickets/148890 (GitLab Internal) ## Issue readiness * [x] Product: issue description is accurate with an acceptable proposal for an MVC * [x] Engineering: issue is implementable with few remaining questions, is sufficiently broken down, and is able to be estimated