Forking project to groups with restricted visibility levels
-
Please check this box if this contribution uses AI-generated content (including content generated by GitLab Duo features) as outlined in the GitLab DCO & CLA
What does this MR do and why?
- This MR is related to #465288 (closed) and #384358 (closed)
- This MR enhances the namespace dropdown (field "Project URL") in the project forking page and allows to fork a project into a group with a restricted visiblity level
- Through this MR, the namespace dropdown suggests public and internal groups even though these visibility levels are restricted; the reasoning is that it should still be possible to fork a private project into an existing public group, see examples in the section "Screenshots or screen recordings"
- MR does not changes the frontend directly, but adjusts the backend GraphQL query to retreive the possible fork targets for a project and user
MR acceptance checklist
Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
MR Checklist (@gerardo-navarro)
-
Changelog entry added, if necessary -
Documentation created/updated via this MR -
Documentation reviewed by technical writer or follow-up review issue created -
Tests added for this feature/bug -
Tested in all supported browsers -
Conforms to the code review guidelines -
Conforms to the merge request performance guidelines -
Conforms to the style guides -
Conforms to the javascript style guides -
Conforms to the database guides
Screenshots or screen recordings
Scenario 1: Restricted visibility levels private
Reasoning: Private groups can only have private projects. But since the private visibility level is restricted, it is not possible to create a private project at all. Hence, it is not possible to create private project in a private group. Therefore, private groups can be disregarded from the namespace dropdown.
| Before | After |
|---|---|
| Private groups are not included in the namespace suggestion. | Public groups are not included in the namespace suggestion. Not changed by this MR. |
 |
 |
 |
 |
Scenario 2: Restricted visibility levels public
Reasoning: Public groups can have public, internal and private projects. But since only the visibility level public is restricted, it is still possible to create an internal and private project in existsing public group. Therefore, we can still suggest public groups in the namespace dropdown, even though the visiblity level public is restricted. Same reasoning can also be applied when only the visibility level internal is restricted.
| Before | After |
|---|---|
| Public groups are not included in the namespace suggestion. | Public groups are included in the namespace suggestion. |
 |
 |
 |
 |
Scenario 3: Restricted visibility levels private and internal
Reasoning: Similar reasoning to scenario 1. Internal groups can only have internal and private projects. But since the visibility levels internal and private are restricted, it is not possible to create an internal and private project as part of an internal or private group. Therefore, we can disregard private and internal groups in the namespace dropdown.
| Before | After |
|---|---|
| Private and internal groups are not included in the namespace suggestion. | Private and internal groups are not included in the namespace suggestion. Not changed by this MR. |
 |
 |
 |
 |
Scenario 4: Restricted visibility levels private and public
Reasoning: Similar reasoning as in scenario 1 and scenario 2. Private groups can be disregarded in the namesspace dropdown because the visibility level private is restricted and therefore it is not possible to create a private (or an internal) project in a private group. However, we do not need to disregard public groups because it is possible to create an internal project in an existing public group.
| Before | After |
|---|---|
| Private and public groups are not included in the namespace suggestion. | Private are not included in the namespace suggestion, but public groups are included. |
 |
 |
 |
 |
Scenario 5: Restricted visibility levels internal and public
Reasoning: Similar reasoning as in scenario 2, public and internal groups can be suggested in the namesspace dropdown because it is possible to create a private project in an existing public group.
| Before | After |
|---|---|
| Private and public groups are not included in the namespace suggestion. | Internal and public groups are included in the namespace suggestion. |
|
|
 |
 |
How to set up and validate locally
- With a non-admin user, create three groups with the different visibility levels
public,internalandprivate - With a non-admin user, create an private project in the internal group
- With an admin user, restrict the visibility levels
publicandinternalin the admin area: http://gdk.test:3000/admin/application_settings/general#js-visibility-settings - With a non-admin user, start forking the new created project
- You should be able to select all created groups as namespaces for the field "Project URL"
👍 - With an admin user, restrict other visibility levels
privateandinternaland see that now the public groups is suggested in the namespace dropdown.
Related to #465288 (closed) and #384358 (closed)