Disable `Internal` visibility setting on GitLab.com

Problem statement

The Internal project visibility can be misleading to users, especially on a public shared service like GitLab.com. Internal seems to convey some type of security, but on GitLab.com means anyone can access it, because sign ups are open.

Proposed solution

Disable the Internal visibility setting on GitLab.com by restricting this visibility setting in the admin panel.

Tested behavior

When enabled on an existing instance:

• New projects, groups, and snippets cannot be created with an Internal visibility setting. This option is greyed out:

• Existing projects, groups, and snippets with a visibility setting of Internal remain Internal. The visibility on these objects can only be modified to Public or Private.

• Attempting to create via the API fails with "message": {"visibility_level": ["internal has been restricted by your GitLab administrator"].

• Admins can create projects, groups, and snippets with any visibility level, including Internal, via the UI or API.

added Manage [DEPRECATED] devopsmanage typefeature labels

cc @jeremy

added to epic &1512 (closed)

changed the description

A smaller iteration here, may be to simply prevent the creation of new internal projects/groups. We can deal with the migration of any projects/groups later.

changed the description

changed title from Option to disable Internal project visibility to Option to disable Internal project visibility during creation of new projects

added customer groupauthentication and authorization [DEPRECATED] labels

My 2c FWIW, all Groups with a paid subscription on .com should be Private by default and can be changed only by opening a ticket with GitLab Inc. Projects under any Group name space should follow the normal Project Visibility settings but be contained to the Group. So if you create an Internal Project, it's only internal the Group. That's the only way to accomplish innersourcing in a .com Group.

Hrm

@jeremy - how does inheritance work for private groups? Would there be an easy way accomplish innersourcing?

I'd be hesitant to make all paid groups be private without the owners having the ability to change it. Users should be able to decide their group's visibility and who has the rights to change that. Group visibility can only be changed by an owner, and we expect users to be cognizant of giving too many users an Owner role (especially a group admin).

If a group is private, then projects are default by private and cannot be changed (to public/internal). An Owner would have to change the whole group to not-private for the projects to be changed to anything else.

Roles are also inherited, so all users of an org can be added as Guest (or higher) so that they can see the projects (and do other Guest level actions which are fairly minimal) without providing all of them the ability to interact at a higher level.

We have numerous groups with a subscription that have public projects because they're open source, but have a subscription because they want the paid group features. This includes all OSS/EDU Gold groups.

Customers who want a mix of public and private I believe have structured it so that the parent group is public, but individual projects are set accordingly, or have all private projects in private subgroups.

Implementing the change would also add a lot of complexity. A subscription cannot be applied to a plan until after the group is created, so how would the system know to force a group to be private when the group is always created with a Free plan?

I'm going to second @cynthia's sentiments. It doesn't make sense to not allow owners of groups to change the visibility of their groups/projects. In fact, I'd go as far as to say that it is insulting to our customers. It suggests that they require babysitting.

When creating new groups/projects, the default selection is already set to private. You need to manually change it to public.

It suggests that they require babysitting.

Is that not the universally accepted assumption? Which quite majestically follows from the esteemed problem statement of our most benevolent ...

The Internal project visibility can be misleading to users, especially on a public shared service like GitLab.com. Internal seems to convey some type of security, but on GitLab.com means anyone can access it, because sign ups are open.

A GitLab Ultimate customer is internally pointing out that us disabling internal effectively forces them to buy more Ultimate seats, because their guests can't read the code in private projects (only issues) they've been invited to. cc @hsutor

@katrinleinweber - did you find #20277 (closed)?

There’s definitely some trade offs - but I think the customer in question would also not be happy if any logged in user on GitLab.com could view the code in their projects. That was the motivation behind this change: we had folks using this setting assuming it meant that only people in their organization would be able to see the project, but in fact it was any logged in GitLab.com user.

Thanks a lot for creating the issue. This would be my preferred approach over changing copy or similar. Moving this to gitlab-ee since this is a GitLab.com specific issue (which runs EE Ultimate).

mentioned in issue #12389 (closed)

@lmcandrew, would you kindly comment here on how challenging this might be? This feels fairly straightforward - perhaps a 2, maybe stretching to a 3? We'll have to consider the API as well.

Moving this to gitlab-ee since this is a GitLab.com specific issue

In theory this setting could be useful to any other GitLab instances that allow open sign up. E.g. GNOME or Framasoft

Challenging this might be? We'll have to consider the API as well.

We already have a restricted_visibility_levels setting we might be able to use for this purpose. I think the first step would be to enable this on an instance and verify that Internal is removed as an option from the UI. I think it is already checked when creating projects/groups. We might also want to verify that it doesn't break existing Internal projects.

changed weight to 3

Thanks for the initial investigation @jamedjo.

The change doesn't seem to complex, so I will add a weight of 3.

changed milestone to %12.1

added groupoptimize label and removed groupauthentication and authorization [DEPRECATED] label