Skip to content

Invite private group to project return 404 error

Summary

When a user is invited directly to a project in a subgroup and the user try to invite the group as a member of another project outside the group, the invitation page redirect to 404 page not found https://gitlab.com/username/projectname/-/group_links

Steps to reproduce

  1. Create private group example-group
  2. Create a private project example-project
  3. Invite a user example-user directly to the example-project
  4. As user example-user, create a project under the user namespace example-user/external-project
  5. As user example-user, invite group example-group to example-user/external-project
  6. See the 404 page

Example Project

(If possible, please create an example project here on GitLab.com that exhibits the problematic behavior, and link to it here in the bug report)

(If you are using an older version of GitLab, this will also determine whether the bug is fixed in a more recent version)

What is the current bug behavior?

User was presented with a 404 page when trying to invite a group to the project

What is the expected correct behavior?

Either show error message of why user cannot invite the group to the project or allow user to invite the group successfully.

Output of checks

This bug happens on GitLab.com 12.10.0-pre cc49b6fe

Proposed Solution

As proposed by @manojmj in this comment, we will proceed with the following approach:

Create an entirely new API to expose "groups that can be shared to current group" and use that API in the frontend to expose the results.

So, along the lines of

GET /groups/:id/share_locations

(similar to https://docs.gitlab.com/ee/api/groups.html#get-groups-to-which-a-user-can-transfer-a-group)

and this API would (via a new finder class),

  • return Group.all for admins.
  • return groups with at least guest access for other users. (we can probably call GroupsFinder internally with min_access_level:10 to get this result)
  • later, include groups arising from group shares in the result set.

I would support this approach specifically because of the fact that the current GroupsFinder is bloated, since we make changes in it to support all the different kinds of use cases we have across the app and it would be better if we do not extend it again. All use cases are not the same, so why make changes in the same class always?

Rather, if we move out this use case to a new finder class entirely, it gives us the flexibility to

  • work on it without the fear of "will this break something?".
  • include changes in the future easily.
Edited by Mansoor Khan