Subgroups where the user is a member is not listed correctly in Your Works > Groups > Member tab

Summary

Subgroups where the user is a member is now shown correctly in Your Works > Groups > Members` tab.

This seems like a bug with the API and likely existed even before the migration.

Steps to reproduce

1. Sign in as User A and create a private group with a subgroup.
2. Invite User B as a member of the subgroup.
3. Sign in as User B and go to /dashboard/groups.

Screenshots

Note:

• Group structure is Audio > Microphone.
• User is a member of Microphone group.
• User is NOT a member of Audio

Your Work > Groups

User Profile > Groups

What is the current bug behavior?

The parent group is displayed with no expand option. Clicking it redirects the user to a 404 page.

What is the expected correct behavior?

a. The subgroup is displayed correctly.

b. The top-level group is displayed with an option to expand. Links/actions on the parent group should be disabled because the user only has access to the subgroup.

Possible fixes

Patch release information for backports

If the bug fix needs to be backported in a patch release to a version under the maintenance policy, please follow the steps on the patch release runbook for GitLab engineers.

Refer to the internal "Release Information" dashboard for information about the next patch release, including the targeted versions, expected release date, and current status.

High-severity bug remediation

To remediate high-severity issues requiring an internal release for single-tenant SaaS instances, refer to the internal release process for engineers.