Visibility permissions of a fork can show weird behavior

ZenDesk: https://gitlab.zendesk.com/agent/tickets/9739

Description of issue

Big Customer is reporting the following behavior with the visibility permissions of a fork. It happens in the following scenario.

1. A master project is initially created with a certain permission (i.e. internal or public)

2. A fork of the project is made, which inherits the same permission (i.e. internal or public)

3. The permission of the master project is changed to be more restrictive (i.e. from internal to private or from public to internal or private)

4. The forked project(s) will then exhibit blocked out permissions, with no way to make it more restrictive.

How to "fix" this:

1. Change the permission of the master project to be one level or more open as the forked projects.

2. Change the permissions on the forked projects to be at least as strict as the master project will be changed to.

3. Change the permission on the master project to be that planned in 2.

Customer's comments

I think ideally, if a master project is made more restrictive, that any forks from it are set to at least that master project’s restriction level, if it isn’t already at that restriction level or more strict.

Replication

I was able to replicate this on 8.0.3-ee

Questions

@vsizov what do you think about this? Is this supposed to be happening?

/cc @JobV