Group share project accessibility issue

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 #224771 (closed).

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.

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 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.

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
• Subgroup (for projects)
• Subgroup (for users only)

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.
2. 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

• Product: issue description is accurate with an acceptable proposal for an MVC
• Engineering: issue is implementable with few remaining questions, is sufficiently broken down, and is able to be estimated