Commit d5a303cf authored by Mark Chao's avatar Mark Chao

Doc update

parent 7c965a24
......@@ -10,7 +10,7 @@
10 => Guest access
20 => Reporter access
30 => Developer access
40 => Master access
40 => Maintainer access
50 => Owner access # Only valid for groups
```
......
......@@ -8,7 +8,7 @@ The access levels are defined in the `Gitlab::Access` module. Currently, these l
10 => Guest access
20 => Reporter access
30 => Developer access
40 => Master access
40 => Maintainer access
50 => Owner access # Only valid for groups
```
......
......@@ -8,7 +8,7 @@ The access levels are defined in the `ProtectedRefAccess::ALLOWED_ACCESS_LEVELS`
```
0 => No access
30 => Developer access
40 => Master access
40 => Maintainer access
```
## List protected branches
......@@ -36,13 +36,13 @@ Example response:
"push_access_levels": [
{
"access_level": 40,
"access_level_description": "Masters"
"access_level_description": "Maintainers"
}
],
"merge_access_levels": [
{
"access_level": 40,
"access_level_description": "Masters"
"access_level_description": "Maintainers"
}
]
},
......@@ -75,13 +75,13 @@ Example response:
"push_access_levels": [
{
"access_level": 40,
"access_level_description": "Masters"
"access_level_description": "Maintainers"
}
],
"merge_access_levels": [
{
"access_level": 40,
"access_level_description": "Masters"
"access_level_description": "Maintainers"
}
]
}
......
# Services API
>**Note:** This API requires an access token with Master or Owner permissions
>**Note:** This API requires an access token with Maintainer or Owner permissions
## Asana
......
......@@ -84,7 +84,7 @@ visit the project you want to make the Runner work for in GitLab:
## Registering a group Runner
Creating a group Runner requires Master permissions for the group. To create a
Creating a group Runner requires Maintainer permissions for the group. To create a
group Runner visit the group you want to make the Runner work for in GitLab:
1. Go to **Settings > CI/CD** to obtain the token
......@@ -120,9 +120,9 @@ To lock/unlock a Runner:
## Assigning a Runner to another project
If you are Master on a project where a specific Runner is assigned to, and the
If you are Maintainer on a project where a specific Runner is assigned to, and the
Runner is not [locked only to that project](#locking-a-specific-runner-from-being-enabled-for-other-projects),
you can enable the Runner also on any other project where you have Master permissions.
you can enable the Runner also on any other project where you have Maintainer permissions.
To enable/disable a Runner in your project:
......@@ -132,7 +132,7 @@ To enable/disable a Runner in your project:
> **Note**:
Consider that if you don't lock your specific Runner to a specific project, any
user with Master role in you project can assign your Runner to another arbitrary
user with Maintainer role in you project can assign your Runner to another arbitrary
project without requiring your authorization, so use it with caution.
An admin can enable/disable a specific Runner for projects:
......
......@@ -327,7 +327,7 @@ this [development guide](https://gitlab.com/gitlab-com/gitlab-docs/blob/master/R
If you want to preview the doc changes of your merge request live, you can use
the manual `review-docs-deploy` job in your merge request. You will need at
least Master permissions to be able to run it and is currently enabled for the
least Maintainer permissions to be able to run it and is currently enabled for the
following projects:
- https://gitlab.com/gitlab-org/gitlab-ce
......
......@@ -138,7 +138,7 @@ Please refer to `group_rename` and `user_rename` for that case.
"created_at": "2012-07-21T07:30:56Z",
"updated_at": "2012-07-21T07:38:22Z",
"event_name": "user_add_to_team",
"project_access": "Master",
"project_access": "Maintainer",
"project_id": 74,
"project_name": "StoreCloud",
"project_path": "storecloud",
......@@ -158,7 +158,7 @@ Please refer to `group_rename` and `user_rename` for that case.
"created_at": "2012-07-21T07:30:56Z",
"updated_at": "2012-07-21T07:38:22Z",
"event_name": "user_remove_from_team",
"project_access": "Master",
"project_access": "Maintainer",
"project_id": 74,
"project_name": "StoreCloud",
"project_path": "storecloud",
......@@ -318,7 +318,7 @@ If the user is blocked via LDAP, `state` will be `ldap_blocked`.
"created_at": "2012-07-21T07:30:56Z",
"updated_at": "2012-07-21T07:38:22Z",
"event_name": "user_add_to_group",
"group_access": "Master",
"group_access": "Maintainer",
"group_id": 78,
"group_name": "StoreCloud",
"group_path": "storecloud",
......@@ -335,7 +335,7 @@ If the user is blocked via LDAP, `state` will be `ldap_blocked`.
"created_at": "2012-07-21T07:30:56Z",
"updated_at": "2012-07-21T07:38:22Z",
"event_name": "user_remove_from_group",
"group_access": "Master",
"group_access": "Maintainer",
"group_id": 78,
"group_name": "StoreCloud",
"group_path": "storecloud",
......
......@@ -11,7 +11,7 @@ You can leave a comment in the following places:
- commit diffs
The comment area supports [Markdown] and [quick actions]. One can edit their
own comment at any time, and anyone with [Master access level][permissions] or
own comment at any time, and anyone with [Maintainer access level][permissions] or
higher can also edit a comment made by someone else.
You could also reply to the notification email in order to reply to a comment,
......@@ -253,7 +253,7 @@ to newer issues or merge requests.
- The people participating in the discussion are trolling, abusive, or otherwise
being unproductive.
In these cases, a user with Master permissions or higher in the project can lock (and unlock)
In these cases, a user with Maintainer permissions or higher in the project can lock (and unlock)
an issue or a merge request, using the "Lock" section in the sidebar:
| Unlock | Lock |
......
......@@ -145,8 +145,8 @@ permissions.
For example, if User0 was first added to group `group-1/group-1-1` with Developer
permissions, then they will inherit those permissions in every other subgroup
of `group-1/group-1-1`. To give them Master access to `group-1/group-1-1/group1-1-1`,
you would add them again in that group as Master. Removing them from that group,
of `group-1/group-1-1`. To give them Maintainer access to `group-1/group-1-1/group1-1-1`,
you would add them again in that group as Maintainer. Removing them from that group,
the permissions will fallback to those of the ancestor group.
## Mentioning subgroups
......
......@@ -27,7 +27,7 @@ See our [product handbook on permissions](https://about.gitlab.com/handbook/prod
The following table depicts the various user permission levels in a project.
| Action | Guest | Reporter | Developer | Master | Owner |
| Action | Guest | Reporter | Developer |Maintainer| Owner |
|---------------------------------------|---------|------------|-------------|----------|--------|
| Create new issue | ✓ [^1] | ✓ | ✓ | ✓ | ✓ |
| Create confidential issue | ✓ [^1] | ✓ | ✓ | ✓ | ✓ |
......@@ -109,7 +109,7 @@ 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
Additionally, you can allow or forbid users with Maintainer 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.
......@@ -150,7 +150,7 @@ 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
group.
| Action | Guest | Reporter | Developer | Master | Owner |
| Action | Guest | Reporter | Developer | Maintainer | Owner |
|-------------------------|-------|----------|-----------|--------|-------|
| Browse group | ✓ | ✓ | ✓ | ✓ | ✓ |
| Edit group | | | | | ✓ |
......@@ -208,7 +208,7 @@ 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`.
| Action | Guest, Reporter | Developer | Master | Admin |
| Action | Guest, Reporter | Developer |Maintainer| Admin |
|---------------------------------------|-----------------|-------------|----------|--------|
| See commits and jobs | ✓ | ✓ | ✓ | ✓ |
| Retry or cancel job | | ✓ | ✓ | ✓ |
......@@ -230,7 +230,7 @@ Read all about the [new model and its implications][new-mod].
This table shows granted privileges for jobs triggered by specific types of
users:
| Action | Guest, Reporter | Developer | Master | Admin |
| Action | Guest, Reporter | Developer |Maintainer| Admin |
|---------------------------------------------|-----------------|-------------|----------|--------|
| Run CI job | | ✓ | ✓ | ✓ |
| Clone source and LFS from current project | | ✓ | ✓ | ✓ |
......@@ -276,7 +276,7 @@ only.
[^1]: On public and internal projects, all users are able to perform this action
[^2]: Guest users can only view the confidential issues they created themselves
[^3]: If **Public pipelines** is enabled in **Project Settings > CI/CD**
[^4]: Not allowed for Guest, Reporter, Developer, Master, or Owner
[^4]: Not allowed for Guest, Reporter, Developer, Maintainer, or Owner
[^5]: Only if the job was triggered by the user
[^6]: Only if user is not external one
[^7]: Only if user is a member of the project
......
......@@ -19,7 +19,7 @@ or provide the credentials to an [existing Kubernetes cluster](#adding-an-existi
## Adding and creating a new GKE cluster via GitLab
NOTE: **Note:**
You need Master [permissions] and above to access the Kubernetes page.
You need Maintainer [permissions] and above to access the Kubernetes page.
Before proceeding, make sure the following requirements are met:
......@@ -30,7 +30,7 @@ Before proceeding, make sure the following requirements are met:
clusters on GKE. That would mean that a [billing
account](https://cloud.google.com/billing/docs/how-to/manage-billing-account)
must be set up and that you have to have permissions to access it.
- You must have Master [permissions] in order to be able to access the
- You must have Maintainer [permissions] in order to be able to access the
**Kubernetes** page.
- You must have [Cloud Billing API](https://cloud.google.com/billing/) enabled
- You must have [Resource Manager
......@@ -66,7 +66,7 @@ enable the Cluster integration.
## Adding an existing Kubernetes cluster
NOTE: **Note:**
You need Master [permissions] and above to access the Kubernetes page.
You need Maintainer [permissions] and above to access the Kubernetes page.
To add an existing Kubernetes cluster to your project:
......@@ -325,7 +325,7 @@ To disable the Kubernetes cluster integration, follow the same procedure.
## Removing the Kubernetes cluster integration
NOTE: **Note:**
You need Master [permissions] and above to remove a Kubernetes cluster integration.
You need Maintainer [permissions] and above to remove a Kubernetes cluster integration.
NOTE: **Note:**
When you remove a cluster, you only remove its relation to GitLab, not the
......
......@@ -71,10 +71,10 @@ least [Reporter access][permissions]. However, a guest user can also create
confidential issues, but can only view the ones that they created themselves.
Confidential issues are also hidden in search results for unprivileged users.
For example, here's what a user with Master and Guest access sees in the
For example, here's what a user with Maintainer and Guest access sees in the
project's search results respectively.
| Master access | Guest access |
| Maintainer access | Guest access |
| :-----------: | :----------: |
| ![Confidential issues search master](img/confidential_issues_search_master.png) | ![Confidential issues search guest](img/confidential_issues_search_guest.png) |
......
......@@ -43,7 +43,7 @@ level to the project.
You can import another project's users in your own project by hitting the
**Import members** button on the upper right corner of the **Members** menu.
In the dropdown menu, you can see only the projects you are Master on.
In the dropdown menu, you can see only the projects you are Maintainer on.
![Import members from another project](img/add_user_import_members_from_another_project.png)
......
......@@ -42,7 +42,7 @@ Admins are able to share projects with any group in the system.
## Maximum access level
In the example above, the maximum access level of 'Developer' for members from 'Engineering' means that users with higher access levels in 'Engineering' ('Master' or 'Owner') will only have 'Developer' access to 'Project Acme'.
In the example above, the maximum access level of 'Developer' for members from 'Engineering' means that users with higher access levels in 'Engineering' ('Maintainer' or 'Owner') will only have 'Developer' access to 'Project Acme'.
## Share project with group lock
......
......@@ -9,7 +9,7 @@ There are two main ways to have a merge request flow with GitLab:
With the protected branch flow everybody works within the same GitLab project.
The project maintainers get Master access and the regular developers get
The project maintainers get Maintainer access and the regular developers get
Developer access.
The maintainers mark the authoritative branches as 'Protected'.
......@@ -18,7 +18,7 @@ The developers push feature branches to the project and create merge requests
to have their feature branches reviewed and merged into one of the protected
branches.
By default, only users with Master access can merge changes into a protected
By default, only users with Maintainer access can merge changes into a protected
branch.
**Advantages**
......@@ -32,7 +32,7 @@ branch.
## Forking workflow
With the forking workflow the maintainers get Master access and the regular
With the forking workflow the maintainers get Maintainer access and the regular
developers get Reporter access to the authoritative repository, which prohibits
them from pushing any changes to it.
......
......@@ -85,7 +85,7 @@ request is merged.
This option is also visible in an existing merge request next to the merge
request button and can be selected/deselected before merging. It's only visible
to users with [Master permissions](../../permissions.md) in the source project.
to users with [Maintainer permissions](../../permissions.md) in the source project.
If the user viewing the merge request does not have the correct permissions to
remove the source branch and the source branch is set for removal, the merge
......
......@@ -10,8 +10,8 @@ created protected branches.
By default, a protected branch does four simple things:
- it prevents its creation, if not already created, from everybody except users
with Master permission
- it prevents pushes from everybody except users with Master permission
with Maintainer permission
- it prevents pushes from everybody except users with Maintainer permission
- it prevents **anyone** from force pushing to the branch
- it prevents **anyone** from deleting the branch
......@@ -24,7 +24,7 @@ See the [Changelog](#changelog) section for changes over time.
## Configuring protected branches
To protect a branch, you need to have at least Master permission level. Note
To protect a branch, you need to have at least Maintainer permission level. Note
that the `master` branch is protected by default.
1. Navigate to your project's **Settings ➔ Repository**
......@@ -45,7 +45,7 @@ that the `master` branch is protected by default.
Since GitLab 8.11, we added another layer of branch protection which provides
more granular management of protected branches. The "Developers can push"
option was replaced by an "Allowed to push" setting which can be set to
allow/prohibit Masters and/or Developers to push to a protected branch.
allow/prohibit Maintainers and/or Developers to push to a protected branch.
Using the "Allowed to push" and "Allowed to merge" settings, you can control
the actions that different roles can perform with the protected branch.
......@@ -66,7 +66,7 @@ dropdown list in the "Already protected" area.
![Developers can push](img/protected_branches_devs_can_push.png)
If you don't choose any of those options while creating a protected branch,
they are set to "Masters" by default.
they are set to "Maintainers" by default.
## Wildcard protected branches
......@@ -101,7 +101,7 @@ all matching branches:
From time to time, it may be required to delete or clean up branches that are
protected.
User with [Master permissions][perm] and up can manually delete protected
User with [Maintainer permissions][perm] and up can manually delete protected
branches via GitLab's web interface:
1. Visit **Repository > Branches**
......
......@@ -8,12 +8,12 @@ This feature evolved out of [Protected Branches](protected_branches.md)
## Overview
Protected tags will prevent anyone from updating or deleting the tag, as and will prevent creation of matching tags based on the permissions you have selected. By default, anyone without Master permission will be prevented from creating tags.
Protected tags will prevent anyone from updating or deleting the tag, as and will prevent creation of matching tags based on the permissions you have selected. By default, anyone without Maintainer permission will be prevented from creating tags.
## Configuring protected tags
To protect a tag, you need to have at least Master permission level.
To protect a tag, you need to have at least Maintainer permission level.
1. Navigate to the project's Settings -> Repository page
......
# Project settings
NOTE: **Note:**
Only project Masters and Admin users have the [permissions] to access a project
Only project Maintainers and Admin users have the [permissions] to access a project
settings.
You can adjust your [project](../index.md) settings by navigating
......@@ -74,7 +74,7 @@ To archive a project:
#### Renaming a repository
NOTE: **Note:**
Only project Masters and Admin users have the [permissions] to rename a
Only project Maintainers and Admin users have the [permissions] to rename a
repository. Not to be confused with a project's name where it can also be
changed from the [general project settings](#general-project-settings).
......@@ -98,7 +98,7 @@ Only project Owners and Admin users have the [permissions] to transfer a project
You can transfer an existing project into a [group](../../group/index.md) if:
1. you have at least **Master** [permissions] to that group
1. you have at least **Maintainer** [permissions] to that group
1. you are an **Owner** of the project.
Similarly, if you are an owner of a group, you can transfer any of its projects
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment