Welcome to mirror list, hosted at ThFree Co, Russian Federation.

gitlab.com/gitlab-org/gitlab-foss.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
Diffstat (limited to 'doc/user/public_access.md')
-rw-r--r--doc/user/public_access.md98
1 files changed, 98 insertions, 0 deletions
diff --git a/doc/user/public_access.md b/doc/user/public_access.md
new file mode 100644
index 00000000000..cca753a2830
--- /dev/null
+++ b/doc/user/public_access.md
@@ -0,0 +1,98 @@
+---
+stage: Manage
+group: Workspace
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+type: reference
+---
+
+# Project and group visibility **(FREE)**
+
+GitLab allows users with the Owner role to set a project's or group's visibility as:
+
+- **Public**
+- **Internal**
+- **Private**
+
+These visibility levels affect who can see the project in the public access directory (`/public`
+for your GitLab instance). For example, <https://gitlab.com/public>.
+You can control the visibility of individual features with
+[project feature settings](permissions.md#project-features).
+
+## Public projects and groups
+
+Public projects can be cloned **without any** authentication over HTTPS.
+
+They are listed in the public access directory (`/public`) for all users.
+
+**Any signed-in user** has the Guest role on the repository.
+
+NOTE:
+By default, `/public` is visible to unauthenticated users. However, if the
+[**Public** visibility level](admin_area/settings/visibility_and_access_controls.md#restrict-visibility-levels)
+is restricted, `/public` is visible only to signed-in users.
+
+## Internal projects and groups
+
+Internal projects can be cloned by any signed-in user except
+[external users](permissions.md#external-users).
+
+They are also listed in the public access directory (`/public`), but only for signed-in users.
+
+Any signed-in users except [external users](permissions.md#external-users) have the
+Guest role on the repository.
+
+NOTE:
+From July 2019, the `Internal` visibility setting is disabled for new projects, groups,
+and snippets on GitLab.com. Existing projects, groups, and snippets using the `Internal`
+visibility setting keep this setting. You can read more about the change in the
+[relevant issue](https://gitlab.com/gitlab-org/gitlab/-/issues/12388).
+
+## Private projects and groups
+
+Private projects can only be cloned and viewed by project members (except for guests).
+
+They appear in the public access directory (`/public`) for project members only.
+
+## Change project visibility
+
+Prerequisite:
+
+- You must have the Owner role for a project.
+
+1. On the top bar, select **Menu > Projects** and find your project.
+1. On the left sidebar, select **Settings > General**.
+1. Expand **Visibility, project features, permissions**.
+1. Change **Project visibility** to either **Private**, **Internal**, or **Public**.
+1. Select **Save changes**.
+
+## Change group visibility
+
+Prerequisite:
+
+- You must have the Owner role for a group.
+
+1. On the top bar, select **Menu > Groups** and find your project.
+1. On the left sidebar, select **Settings > General**.
+1. Expand **Naming, visibility**.
+1. Under **Visibility level** select either **Private**, **Internal**, or **Public**.
+1. Select **Save changes**.
+
+## Restrict use of public or internal projects **(FREE SELF)**
+
+You can restrict the use of visibility levels for users when they create a project or a snippet.
+This is useful to prevent users from publicly exposing their repositories by accident. The
+restricted visibility settings do not apply to administrators.
+
+For details, see [Restricted visibility levels](admin_area/settings/visibility_and_access_controls.md#restrict-visibility-levels).
+
+<!-- ## Troubleshooting
+
+Include any troubleshooting steps that you can foresee. If you know beforehand what issues
+one might have when setting this up, or when something is changed, or on upgrading, it's
+important to describe those, too. Think of things that may go wrong and include them here.
+This is important to minimize requests for support, and to avoid doc comments with
+questions that you know someone might ask.
+
+Each scenario can be a third-level heading, e.g. `### Getting error message X`.
+If you have none to add when creating a doc, leave this section in place
+but commented out to help encourage others to add to it in the future. -->