Prevent forking outside a private group (#216987) · Issues · GitLab.org / GitLab

Prevent forking outside a private group

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 private groups, a group Owner should be able to toggle whether or not forks can be created outside of the group.

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.

Permissions and Security

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

Documentation

Availability & Testing

Links / references

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

Other providers:

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

### 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

<!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later.

Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/

* [Cameron (Compliance Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#cameron-compliance-manager)
* [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead)
* [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer)
* [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer)
* [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator)
* [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst)
* [Rachel (Release Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#rachel-release-manager) 
* [Alex (Security Operations Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#alex-security-operations-engineer)
* [Simone (Software Engineer in Test)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#simone-software-engineer-in-test)
* [Allison (Application Ops)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#allison-application-ops) 
* [Priyanka (Platform Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#priyanka-platform-engineer)
-->

### User experience goal

### Proposal

For private groups, a group Owner should be able to toggle whether or not forks can be created outside of the group.

* 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.

### Permissions and Security

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

### Documentation

<!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/workflow.html#for-a-product-change

* Add all known Documentation Requirements in this section. See https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements
* If this feature requires changing permissions, update the permissions document. See https://docs.gitlab.com/ee/user/permissions.html -->

### Availability & Testing

<!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier.

What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing?

Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance.
* Unit test changes
* Integration test changes
* End-to-end test change

See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning -->

### Links / references
Existing Functionality:
![Screen_Shot_2020-05-07_at_2.47.18_PM](/uploads/cb837e9d67dfde420787788aa50ccef3/Screen_Shot_2020-05-07_at_2.47.18_PM.png)
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

* [x] Product: issue description is accurate with an acceptable proposal for an MVC
* [x] Engineering: issue is implementable with few remaining questions, is sufficiently broken down, and is able to be estimated

Edited May 18, 2020 by Melissa Ushakov

Discussion
Designs