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
Create private group example-group
Create a private project example-project
Invite a user example-user directly to the example-project
As user example-user, create a project under the user namespace example-user/external-project
As user example-user, invite group example-group to example-user/external-project
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.
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?".
I have stumbled upon this, or at least the immediate symptoms of "404 trying to invite group".
In my case, it is an external agency that I want to grant access to a private repository. Is this not possible? The UI makes it look possible, but then the 404...
I have this issue as well.
When I would like to invite group to my project tecky-exercises, it shows 404 even I delete and re-generate the repository... please gitlab help to solve..
We'd like to allow private forks of one of organization's repositories, then allowing access to this new fork for organization members. It doesn't work, 404 is returned every time.
@hsutor@ogolowinski could you please review this issue or advise if there is a separate issue we should be following? Customer https://gitlab.my.salesforce.com/00161000004zrG3 is experiencing this bug, where sharing a project with a group using the API is failing with a 404, and they would like to see the fix prioritized.
Use case:
We have a team who are managing a large project on behalf of all other engineering teams in the firm. They are trying to construct some basic automation to make this more manageable. Their own project is public and has no restrictions so broad access isn't a concern.
@hsutor, it fails because of a permission check on the group. The user wants to share their personal project with a group they are not member of - only a member of a project within that group. Access typically only flows down in the hierarchy, not up.
An exception to that (and probably a source of confusion in this case) is that project members has limited access to the parent group. However, this particular permission which is involved in sharing is not granted. In my opinion, we should avoid expanding the list of permission that flows up in hierarchy, and I would keep the requirement for the user to be a member of the group. These exceptions are very confusing and counter-intuitive. It is also inconsistently applied: eg. subgroup members do not have access to the parent group, see #36658 (closed).
@ifarkas@hsutor Yes, this has always seemed really inconsistent to me. Something that needs to be resolved from the product level :( Imre, do you recall why we have this exception?
In my opinion, we should avoid expanding the list of permission that flows up in hierarchy, and I would keep the requirement for the user to be a member of the group.
Absolutely. The quirk here is that a project or group member can see epics, milestones, and iterations created in groups above them. Therefore, there's some kind of implicit visibility back up the hierarchy. I've had many discussions with @gweaver on this one.
I've had many discussions with @gweaver on this one.
Were these discussions happening on issues? I would be interested to read them through. This is something we likely need to resolve for group / project consolidation.
@ifarkas Some discussion happened in issues, others happened over zoom. The core problem right now is that our Namespace hierarchy is too rigid. Merging Group and Project into Namespace only solves Problem Set 2 (#218333 (closed)), but we still very much have Problem Set 1 that remains unsolved. We originally pitched a more formal DAG (#254991 (closed)), but there was push back that it was far too complex.
Here are some relevant issues with additional context that are all basically just permutations of ideas on how to solve the same fundamental problem of flowing objects up/down/across Namespace hierarchies:
#25233 (comment 649096555) -- in this particular case, my diagram and assumptions about how the system behaved were incorrect. If a user is added to a deeply nested project, they can navigate to their parent group and view Boards in the parent group. They can see all the issues from their deeply nested project (and until recently when we correctly enforced permissions and then had to revert the correction) were able to drag issues from their project in the parent group board. This made me step back and think deeply about this problem. Let me illustrate further below...
User:Bob can see Group and navigate to it even though he is not a Member.
User:Bob can see both Assignee lists in the Board even though he does not have access to ProjectB and theoretically shouldn't be able to see User:Sam.
Because User:Bob has access to IssueY as a Reporter of ProjectA, and because he can see IssueY within Group, should he be able to edit that issue from anywhere in the hierarchy? I would say yes.
Should User:Bob be able to see Group_Board in the first place? I don't think so, but that is not the current behavior of the system, and as I've recently found, changing it is considering a "breaking change" and regression from a customer perspective.
This is the sort of stuff we need to tease out and figure out how to approach is standardized, consistent manner
Should User:Bob be able to see Group_Board in the first place? I don't think so, but that is not the current behavior of the system, and as I've recently found, changing it is considering a "breaking change" and regression from a customer perspective.
I agree with this. Any exception to access flows down is very confusing.
They can see all the issues from their deeply nested project (and until recently when we correctly enforced permissions and then had to revert the correction) were able to drag issues from their project in the parent group board.
I see how this is considered a breaking change unfortunately. Do you have a link to the MR?
graph Group --> Subgroup Subgroup --> Project Group --> Group_Board User:Bob -->|Developer| Subgroup
When there is a project in the hierarchy, the user has access to both Group and Group_Board, even though they don't have membership in the top-level group.
graph Group --> Subgroup Group --> Group_Board User:Bob -->|Developer| Subgroup
When there is no project in the hierarchy, the user does not have access to Group or Group_Board.
@ifarkas here is the relevant MR - !68126 (merged). Also, I did not tag everyone cc'd above, but this is another relevant thread that may be of interest where I highlight some of these "inconsistent" behaviors from a broader perspective -- #338819 (comment 667830288).
As we move towards groups and projects consolidation I think we will have to introduce a breaking change one way or the other, because eventually we will remove projects and everything will just be a Namespace(group) with the functionality parity, so we'll need to decide which way we want this to work.
When there is a project in the hierarchy, the user has access to both Group and Group_Board, even though they don't have membership in the top-level group.
I wonder if this is something that we did in order to allow members of Project to be able to see Group level items, like labels, milestones, epics, etc, but actually it should work the same way as it currently works for Groups? For groups we perhaps did not have the same need, as we did not have the items that required such permissions, i.e. no issues, not MRs
So, if we could come up with a different way of exposing those relevant items(labels, milestones, epics, etc) at the project level without having to grant project members read permission the entire Group, that would also work? Or are there other different reason for having the members in the project have read permission in the entire Group?
I wonder if this is something that we did in order to allow members of Project to be able to see Group level items, like labels, milestones, epics, etc, but actually it should work the same way as it currently works for Groups?
Yes, my guess is that was the main reason for granting this permission (plus being able to see the group path/reference/breadcrumbs?). It would be awesome to get rid of this permission "flow" exception (IOW not grant access to ancestor resources), such change of behavior would be too big though.
Another (less invasive) option would be to be more restrictive to what resources from ancestor groups are accessible (e.g. user could only list title and id of ancestor labels/milestones/epics... w/o accessing their details), but you could argue this doesn't make situation less confusing as the exception still remains.
If we keep granting access to ancestor groups, it would be really good to address #36658 (closed) as this inconsistency adds extra level of confusion.
@jarka, I think this is related to project sharing, while #351441 (closed) is related to user login via SSO. The root cause here seem to be point to the root cause of many other issues: #340421 (closed). #351441 (closed) does not seem to match - although we haven't investigated it yet.
This ~"group::authentication and authorization" bug has at most 25% of the SLO duration remaining and is ~"approaching-SLO" breach. Please consider taking action before this becomes a ~"missed-SLO" in 14 days (2022-05-21).