User profiles are public even for instances with only private projects

• Zendesk ticket: https://gitlab.zendesk.com/agent/tickets/10841 and https://gitlab.zendesk.com/agent/tickets/17072
• Dev link: https://dev.gitlab.org/gitlab/gitlabhq/issues/2625 and https://dev.gitlab.org/gitlab/gitlabhq/issues/1361
• GitLab version: 8.1.4

In 8.0 we made the decision to make all user profiles public. In cases like GitLab.com this makes a lot of sense. For companies where all projects are private this may be a concern. The GitLab instance might be publicly accessible if the company wants employees to be able to access GitLab from anywhere. However, they don't want to have user details public such as username and name.

In https://dev.gitlab.org/gitlab/gitlabhq/issues/1361 it was suggested that we implement a 'private mode' or a scenario where profiles are not public if public projects are restricted. I think we should reconsider this idea.

cc/ @JobV @sytses @dzaporozhets

There was definitely another issue in the CE tracker sharing the same concern which I cannot find right now.

We should update the documentation in https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/public_access/public_access.md /cc @dzaporozhets

@sytses yes documentation should be updated. @axil can you take care of it?

According to issue: as developer I like to keep everything simple and leave all profiles public as is. But I can see a case when you don't allow information like employee names leak to outside world. And I think since GitLab primary use-case is private hosting - we can consider implementing so named 'Private mode' checkbox when all profiles and groups are hidden. But I would implement it really simple: all user and group profiles are hidden for visitors even if users has public projects.

Something like:

if private_mode?
 return 404 unless current_user
end

Yes, I'll do it.

Relevant issue #2973 (closed) and MR to reflect current behavior !1837 (merged)

@JobV Can we schedule this for an upcoming release?

Added ~134075 label

mentioned in issue #3911 (closed)

mentioned in issue #2973 (closed)

This is brought up quite frequently. I added the Public access label to gather all the issues https://gitlab.com/gitlab-org/gitlab-ce/issues?label_name=Public+access

Thanks @axil.

Milestone changed to 8.6

mentioned in issue #4017 (closed)

@DouweM Will this make 8.6? I have another customer requesting this, critically.

Added ~113220 feature proposal labels

mentioned in issue #14034 (closed)

An issue about the same thing was opened 11 days ago at https://gitlab.com/gitlab-org/gitlab-ce/issues/14034, and @dzaporozhets and I discussed it some more there, unaware of this existing issue.

The conclusion is to not add a private_mode checkbox, but to:

copy the behavior of the restricted_visibility_levels setting. If that doesn't include public, users aren't public.

With https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/3051 in 8.6, disabling "Public" under "Restricted visibility levels" will turn your GitLab instance private from anonymous users.

@dblessing It likely won't make 8.6 because it got lost among smaller "non-customer" issues. I can promise 8.7.

However, @felipe_artur if you have time left this week after https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/3051, please focus on this since you're already deep in visibility code. It would be awesome to get this into 8.6.

Milestone changed to 8.7

Reassigned to @felipe_artur

mentioned in merge request !3440 (merged)

mentioned in commit 58665b64

Status changed to closed

mentioned in issue #17388 (moved)

mentioned in merge request !14785