Merge branch 'docs-topic-permissions' into 'master'

Docs: New index for permissions

Closes #32577

See merge request !13394
This commit is contained in:
Achilleas Pipinellis 2017-08-15 17:58:21 +00:00
commit f82d8a2218

View file

@ -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
## GitLab CI/CD permissions
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 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