From b68e64629a929b6610c20c320340271e3d1ab73f Mon Sep 17 00:00:00 2001 From: Marcia Ramos Date: Tue, 15 Aug 2017 17:58:21 +0000 Subject: Docs: New index for permissions --- doc/user/permissions.md | 109 +++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 90 insertions(+), 19 deletions(-) diff --git a/doc/user/permissions.md b/doc/user/permissions.md index 555b0cf77ea..dcf210e1085 100644 --- a/doc/user/permissions.md +++ b/doc/user/permissions.md @@ -5,17 +5,17 @@ particular group or project. If a user is both in a group's project and the project itself, the highest permission level is used. On public and internal projects the Guest role is not enforced. All users will -be able to create issues, leave comments, and pull or download the project code. +be able to create issues, leave comments, and clone or download the project code. -When a member leaves the team the all assigned Issues and Merge Requests +When a member leaves the team all the assigned [Issues](project/issues/index.md) and [Merge Requests](project/merge_requests/index.md) will be unassigned automatically. -GitLab administrators receive all permissions. +GitLab [administrators](../README.md#administrator-documentation) receive all permissions. To add or import a user, you can follow the [project members documentation](../user/project/members/index.md). -## Project +## Project members permissions The following table depicts the various user permission levels in a project. @@ -75,7 +75,58 @@ The following table depicts the various user permission levels in a project. | Remove protected branches [^3] | | | | | | | Remove pages | | | | | ✓ | -## Group +## Project features permissions + +### Wiki and issues + +Project features like wiki and issues can be hidden from users depending on +which visibility level you select on project settings. + +- Disabled: disabled for everyone +- Only team members: only team members will see even if your project is public or internal +- Everyone with access: everyone can see depending on your project visibility level + +### Protected branches + +To prevent people from messing with history or pushing code without +review, we've created protected branches. Read through the documentation on +[protected branches](project/protected_branches.md) +to learn more. + +Additionally, you can allow or forbid users with Master and/or +Developer permissions to push to a protected branch. Read through the documentation on +[Allowed to Merge and Allowed to Push settings](project/protected_branches.md#using-the-allowed-to-merge-and-allowed-to-push-settings) +to learn more. + +### Cycle Analytics permissions + +Find the current permissions on the Cycle Analytics dashboard on +the [documentation on Cycle Analytics permissions](project/cycle_analytics.md#permissions). + +### Issue Board permissions + +Developers and users with higher permission level can use all +the functionality of the Issue Board, that is create/delete lists +and drag issues around. Read though the +[documentation on Issue Boards permissions](project/issue_board.md#permissions) +to learn more. + +### File Locking permissions (EEP) + +The user that locks a file or directory is the only one that can edit and push their changes back to the repository where the locked objects are located. + +Read through the documentation on [permissions for File Locking](https://docs.gitlab.com/ee/user/project/file_lock.html#permissions-on-file-locking) to learn more. + +File Locking is available in +[GitLab Enterprise Edition Premium](https://about.gitlab.com/gitlab-ee/) only. + +### Confidential Issues permissions + +Confidential issues can be accessed by reporters and higher permission levels, +as well as by guest users that create a confidential issue. To learn more, +read through the documentation on [permissions and access to confidential issues](project/issues/confidential_issues.md#permissions-and-access-to-confidential-issues). + +## Group members permissions Any user can remove themselves from a group, unless they are the last Owner of the group. The following table depicts the various user permission levels in a @@ -91,7 +142,16 @@ group. | Remove group | | | | | ✓ | | Manage group labels | | ✓ | ✓ | ✓ | ✓ | -## External Users +### Subgroup permissions + +When you add a member to a subgroup, they inherit the membership and +permission level from the parent group. This model allows access to +nested groups if you have membership in one of its parents. + +To learn more, read through the documentation on +[subgroups memberships](group/subgroups/index.md#membership). + +## External users permissions In cases where it is desired that a user has access only to some internal or private projects, there is the option of creating **External Users**. This @@ -115,18 +175,9 @@ will find the option to flag the user as external. By default new users are not set as external users. This behavior can be changed by an administrator under **Admin > Application Settings**. -## Project features - -Project features like wiki and issues can be hidden from users depending on -which visibility level you select on project settings. - -- Disabled: disabled for everyone -- Only team members: only team members will see even if your project is public or internal -- Everyone with access: everyone can see depending on your project visibility level - -## GitLab CI +## GitLab CI/CD permissions -GitLab CI permissions rely on the role the user has in GitLab. There are four +GitLab CI/CD permissions rely on the role the user has in GitLab. There are four permission levels in total: - admin @@ -134,7 +185,7 @@ permission levels in total: - developer - guest/reporter -The admin user can perform any action on GitLab CI in scope of the GitLab +The admin user can perform any action on GitLab CI/CD in scope of the GitLab instance and project. In addition, all admins can use the admin interface under `/admin/runners`. @@ -150,7 +201,7 @@ instance and project. In addition, all admins can use the admin interface under | See events in the system | | | | ✓ | | Admin interface | | | | ✓ | -### Jobs permissions +### Job permissions >**Note:** GitLab 8.12 has a completely redesigned job permissions system. @@ -174,6 +225,26 @@ users: | Push container images to current project | | ✓ | ✓ | ✓ | | Push container images to other projects | | | | | +### New CI job permissions model + +GitLab 8.12 has a completely redesigned job permissions system. To learn more, +read through the documentation on the [new CI/CD permissions model](project/new_ci_build_permissions_model.md#new-ci-job-permissions-model). + +## LDAP users permissions + +Since GitLab 8.15, LDAP user permissions can now be manually overridden by an admin user. +Read through the documentation on [LDAP users permissions](https://docs.gitlab.com/ee/articles/how_to_configure_ldap_gitlab_ee/index.html#updating-user-permissions-new-feature) to learn more. + +## Auditor users permissions (EEP) + +An Auditor user should be able to access all projects and groups of a GitLab instance +with the permissions described on the documentation on [auditor users permissions](https://docs.gitlab.com/ee/administration/auditor_users.html#permissions-and-restrictions-of-an-auditor-user). + +Auditor users are available in [GitLab Enterprise Edition Premium](https://about.gitlab.com/gitlab-ee/) +only. + +---- + [^1]: Guest users can only view the confidential issues they created themselves [^2]: If **Public pipelines** is enabled in **Project Settings > Pipelines** [^3]: Not allowed for Guest, Reporter, Developer, Master, or Owner -- cgit v1.2.1