GitLab Next

Problem to solve

Customers with intellectual property want to prevent their data from leaking. We built a feature to prevent forking outside a group that can be used with GMA. Customers want to be able to take advantage of this functionality in any group.

Intended users

User experience goal

Groups owners feel confident that their intellectual property is safe. Group members receive clear explanations about why they can't fork. There is a clear alternative path for them to follow to do their work.

Proposal

For groups, a group Owner should be able to toggle whether or not forks can be created outside of the group in the top level group. The setting should be inherited down to all projects in that subgroup.

• When enabled, creating a fork should only be allowed if the fork is created inside the group.
• When disabled, group members should be able to fork anywhere.
• Option should be available for Silver level and above.

This option should be disabled by default (changing behavior of existing groups is not desired). Note that this restriction would only apply to attempts to create new forks and won't affect any existing forks that are already in personal namespaces, which we should make clear in the documentation. This setting should inherit down a group hierarchy just like the "Private" setting.

Further details

As part of this change, we should remove this option from the Managed Accounts section so there's not 2 places to do the same thing. This option should be available to both private and public groups. It should only be able to be applied in the top level group and the setting flows down to all projects underneath.

Permissions and Security

This will live within group settings so the same permission rules apply as with other options there.

Documentation

Availability & Testing

What risks does this change pose to our availability?

This feature does would not affect GitLab.com or self managed instance's availability as a whole. In the worst case, forking might get be disabled for all users.

What additional test coverage or changes to tests will be needed?

• When forking restriction is disabled on a group:

  • Any user should be able to fork a project. (Existing functionality and should be already covered by tests)

• When forking restriction is enabled on a group:

  • A user (including owner) should not be able to fork a project to outside of group.
  • All users should should be able to fork a project to inside of the group.
  • A user (including owner) should not be able to fork a project in a sub-group to outside of group.

Tests should be added for the fork API as well.

New end-to-end tests are not needed as the coverage at lower level should be enough. However, we should ensure existing end-to-end tests are green by running the package-and-qa manual job.

Links / references

Existing Functionality in Projects: https://docs.gitlab.com/ee/user/group/saml_sso/#outer-forks-restriction-for-group-managed-accounts

Other providers:

• https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/managing-the-forking-policy-for-your-organization
• https://confluence.atlassian.com/bitbucketserver/using-forks-in-bitbucket-server-776639958.html

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