Commit e9ad837c authored by Sean McGivern's avatar Sean McGivern

Merge branch '42751-rename-master-to-maintainer' into 'master'

Resolve "Rename the `Master` role to `Maintainer`"

Closes #42751

See merge request gitlab-org/gitlab-ce!19080
parents 005bc944 dd42cab9
......@@ -8,8 +8,8 @@ module ProtectedRefAccess
].freeze
HUMAN_ACCESS_LEVELS = {
Gitlab::Access::MASTER => "Masters".freeze,
Gitlab::Access::DEVELOPER => "Developers + Masters".freeze,
Gitlab::Access::MASTER => "Maintainers".freeze,
Gitlab::Access::DEVELOPER => "Developers + Maintainers".freeze,
Gitlab::Access::NO_ACCESS => "No one".freeze
}.freeze
......
......@@ -5,7 +5,7 @@ class ProtectedBranch < ActiveRecord::Base
protected_ref_access_levels :merge, :push
def self.protected_ref_accessible_to?(ref, user, project:, action:, protected_refs: nil)
# Masters, owners and admins are allowed to create the default branch
# Maintainers, owners and admins are allowed to create the default branch
if default_branch_protected? && project.empty_repo?
return true if user.admin? || project.team.max_member_access(user.id) > Gitlab::Access::DEVELOPER
end
......
......@@ -45,7 +45,7 @@ class ProjectPolicy < BasePolicy
desc "User has developer access"
condition(:developer) { team_access_level >= Gitlab::Access::DEVELOPER }
desc "User has master access"
desc "User has maintainer access"
condition(:master) { team_access_level >= Gitlab::Access::MASTER }
desc "Project is public"
......
......@@ -24,7 +24,7 @@ module Lfs
success(lock: lock, http_status: :ok)
elsif forced
error(_('You must have master access to force delete a lock'), 403)
error(_('You must have maintainer access to force delete a lock'), 403)
else
error(_("%{lock_path} is locked by GitLab User %{lock_user_id}") % { lock_path: lock.path, lock_user_id: lock.user_id }, 403)
end
......
......@@ -72,7 +72,7 @@
- else
%button{ class: "btn btn-remove remove-row js-ajax-loading-spinner has-tooltip disabled",
disabled: true,
title: s_('Branches|Only a project master or owner can delete a protected branch') }
title: s_('Branches|Only a project maintainer or owner can delete a protected branch') }
= icon("trash-o")
- else
= link_to project_branch_path(@project, branch.name),
......
......@@ -12,7 +12,7 @@
- else
%p
Members can be added by project
%i Masters
%i Maintainers
or
%i Owners
.light
......
......@@ -12,8 +12,8 @@
%p
By default, protected branches are designed to:
%ul
%li prevent their creation, if not already created, from everybody except Masters
%li prevent pushes from everybody except Masters
%li prevent their creation, if not already created, from everybody except Maintainers
%li prevent pushes from everybody except Maintainers
%li prevent <strong>anyone</strong> from force pushing to the branch
%li prevent <strong>anyone</strong> from deleting the branch
%p Read more about #{link_to "protected branches", help_page_path("user/project/protected_branches")} and #{link_to "project permissions", help_page_path("user/permissions")}.
......
......@@ -12,7 +12,7 @@
%p
By default, protected tags are designed to:
%ul
%li Prevent tag creation by everybody except Masters
%li Prevent tag creation by everybody except Maintainers
%li Prevent <strong>anyone</strong> from updating the tag
%li Prevent <strong>anyone</strong> from deleting the tag
......
......@@ -26,9 +26,9 @@
- if can?(current_user, :admin_pipeline, @project.group)
- group_link = link_to _('Group CI/CD settings'), group_settings_ci_cd_path(@project.group)
= _('Group masters can register group runners in the %{link}').html_safe % { link: group_link }
= _('Group maintainers can register group runners in the %{link}').html_safe % { link: group_link }
- else
= _('Ask your group master to setup a group Runner.')
= _('Ask your group maintainer to setup a group Runner.')
- else
%h4.underlined-title
......
---
title: Rename the Master role to Maintainer
merge_request: 19080
author:
type: changed
......@@ -191,7 +191,7 @@ instant how code changes impact your production environment.
- [User account](user/profile/index.md): Manage your account
- [Authentication](topics/authentication/index.md): Account security with two-factor authentication, setup your ssh keys and deploy keys for secure access to your projects.
- [Profile settings](user/profile/index.md#profile-settings): Manage your profile settings, two factor authentication and more.
- [User permissions](user/permissions.md): Learn what each role in a project (external/guest/reporter/developer/master/owner) can do.
- [User permissions](user/permissions.md): Learn what each role in a project (external/guest/reporter/developer/maintainer/owner) can do.
### Git and GitLab
......
......@@ -2,7 +2,7 @@
>
[Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7690)
in GitLab 8.15. Only project masters and owners can access web terminals.
in GitLab 8.15. Only project maintainers and owners can access web terminals.
With the introduction of the [Kubernetes integration](../../user/project/clusters/index.md),
GitLab gained the ability to store and use credentials for a Kubernetes cluster.
......
......@@ -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
```
......
......@@ -54,7 +54,7 @@ Example response:
]
```
**Note**: `members_count_with_descendants` are presented only for group masters/owners.
**Note**: `members_count_with_descendants` are presented only for group maintainers/owners.
## Search for namespace
......
......@@ -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"
}
]
}
......@@ -104,8 +104,8 @@ curl --request POST --header "PRIVATE-TOKEN: 9koXpg98eAheJpvBs5tK" 'https://gitl
| --------- | ---- | -------- | ----------- |
| `id` | integer/string | yes | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user |
| `name` | string | yes | The name of the branch or wildcard |
| `push_access_level` | string | no | Access levels allowed to push (defaults: `40`, master access level) |
| `merge_access_level` | string | no | Access levels allowed to merge (defaults: `40`, master access level) |
| `push_access_level` | string | no | Access levels allowed to push (defaults: `40`, maintainer access level) |
| `merge_access_level` | string | no | Access levels allowed to merge (defaults: `40`, maintainer access level) |
Example response:
......@@ -115,13 +115,13 @@ Example response:
"push_access_levels": [
{
"access_level": 30,
"access_level_description": "Developers + Masters"
"access_level_description": "Developers + Maintainers"
}
],
"merge_access_levels": [
{
"access_level": 30,
"access_level_description": "Developers + Masters"
"access_level_description": "Developers + 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
......
......@@ -81,7 +81,7 @@ PUT /application/settings
| `clientside_sentry_enabled` | boolean | no | Enable Sentry error reporting for the client side |
| `container_registry_token_expire_delay` | integer | no | Container Registry token duration in minutes |
| `default_artifacts_expire_in` | string | no | Set the default expiration time for each job's artifacts |
| `default_branch_protection` | integer | no | Determine if developers can push to master. Can take `0` _(not protected, both developers and masters can push new commits, force push, or delete the branch)_, `1` _(partially protected, developers and masters can push new commits, but cannot force push or delete the branch)_ or `2` _(fully protected, developers cannot push new commits, but masters can; no-one can force push or delete the branch)_ as a parameter. Default is `2`. |
| `default_branch_protection` | integer | no | Determine if developers can push to master. Can take `0` _(not protected, both developers and maintainers can push new commits, force push, or delete the branch)_, `1` _(partially protected, developers and maintainers can push new commits, but cannot force push or delete the branch)_ or `2` _(fully protected, developers cannot push new commits, but maintainers can; no-one can force push or delete the branch)_ as a parameter. Default is `2`. |
| `default_group_visibility` | string | no | What visibility level new groups receive. Can take `private`, `internal` and `public` as a parameter. Default is `private`. |
| `default_project_visibility` | string | no | What visibility level new projects receive. Can take `private`, `internal` and `public` as a parameter. Default is `private`. |
| `default_projects_limit` | integer | no | Project limit per user. Default is `100000` |
......
......@@ -593,7 +593,7 @@ version of the app, all without leaving GitLab.
>**Note:**
Web terminals were added in GitLab 8.15 and are only available to project
masters and owners.
maintainers and owners.
If you deploy to your environments with the help of a deployment service (e.g.,
the [Kubernetes integration][kube]), GitLab can open
......
......@@ -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
......
......@@ -2,7 +2,7 @@
Git is a distributed version control system (DVCS).
This means that everyone that works with the source code has a local copy of the complete repository.
In GitLab every project member that is not a guest (so reporters, developers and masters) can clone the repository to get a local copy.
In GitLab every project member that is not a guest (so reporters, developers and maintainers) can clone the repository to get a local copy.
After obtaining this local copy the user can upload the full repository anywhere, including another project under their control or another server.
The consequence is that you can't build access controls that prevent the intentional sharing of source code by users that have access to the source code.
This is an inherent feature of a DVCS and all git management systems have this limitation.
......
......@@ -2,7 +2,7 @@
If you have non-GitLab web services running on your GitLab server or within its local network, these may be vulnerable to exploitation via Webhooks.
With [Webhooks](../user/project/integrations/webhooks.md), you and your project masters and owners can set up URLs to be triggered when specific things happen to projects. Normally, these requests are sent to external web services specifically set up for this purpose, that process the request and its attached data in some appropriate way.
With [Webhooks](../user/project/integrations/webhooks.md), you and your project maintainers and owners can set up URLs to be triggered when specific things happen to projects. Normally, these requests are sent to external web services specifically set up for this purpose, that process the request and its attached data in some appropriate way.
Things get hairy, however, when a Webhook is set up with a URL that doesn't point to an external, but to an internal service, that may do something completely unintended when the webhook is triggered and the POST request is sent.
......
......@@ -171,7 +171,7 @@ This is really useful for cloning repositories to your Continuous
Integration (CI) server. By using deploy keys, you don't have to set up a
dummy user account.
If you are a project master or owner, you can add a deploy key in the
If you are a project maintainer or owner, you can add a deploy key in the
project settings under the section 'Repository'. Specify a title for the new
deploy key and paste a public SSH key. After this, the machine that uses
the corresponding private SSH key has read-only or read-write (if enabled)
......@@ -196,7 +196,7 @@ This is really useful for integrating repositories to secured, shared Continuous
Integration (CI) services or other shared services.
GitLab administrators can set up the Global Shared Deploy key in GitLab and
add the private key to any shared systems. Individual repositories opt into
exposing their repository using these keys when a project masters (or higher)
exposing their repository using these keys when a project maintainers (or higher)
authorizes a Global Shared Deploy key to be used with their project.
Global Shared Keys can provide greater security compared to Per-Project Deploy
......@@ -205,7 +205,7 @@ who needs to know and configure the private key.
GitLab administrators set up Global Deploy keys in the Admin area under the
section **Deploy Keys**. Ensure keys have a meaningful title as that will be
the primary way for project masters and owners to identify the correct Global
the primary way for project maintainers and owners to identify the correct Global
Deploy key to add. For instance, if the key gives access to a SaaS CI instance,
use the name of that service in the key name if that is all it is used for.
When creating Global Shared Deploy keys, give some thought to the granularity
......@@ -213,7 +213,7 @@ of keys - they could be of very narrow usage such as just a specific service or
of broader usage for something like "Anywhere you need to give read access to
your repository".
Once a GitLab administrator adds the Global Deployment key, project masters
Once a GitLab administrator adds the Global Deployment key, project maintainers
and owners can add it in project's **Settings > Repository** section by expanding the
**Deploy Key** section and clicking **Enable** next to the appropriate key listed
under **Public deploy keys available to any project**.
......
......@@ -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 |
......
......@@ -125,7 +125,7 @@ side of your screen.
---
Group owners and masters will be notified of your request and will be able to approve or
Group owners and maintainers will be notified of your request and will be able to approve or
decline it on the members page.
![Manage access requests](img/access_requests_management.png)
......
......@@ -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
......
......@@ -110,7 +110,7 @@ personal access tokens, authorized applications, etc.
- [Authentication](../topics/authentication/index.md): Read through the authentication
methods available in GitLab.
- [Permissions](permissions.md): Learn the different set of permissions levels for each
user type (guest, reporter, developer, master, owner).
user type (guest, reporter, developer, maintainer, owner).
- [Feature highlight](feature_highlight.md): Learn more about the little blue dots
around the app that explain certain features
......
......@@ -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 | | | | | ✓ |
......@@ -200,7 +200,7 @@ GitLab CI/CD permissions rely on the role the user has in GitLab. There are four
permission levels in total:
- admin
- master
- maintainer
- developer
- guest/reporter
......@@ -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
......@@ -382,7 +382,7 @@ you will need the Kubernetes project integration enabled.
### Web terminals
NOTE: **Note:**
Introduced in GitLab 8.15. You must be the project owner or have `master` permissions
Introduced in GitLab 8.15. You must be the project owner or have `maintainer` permissions
to use terminals. Support is limited to the first container in the
first pod of your environment.
......
......@@ -5,7 +5,7 @@
Deploy tokens allow to download (through `git clone`), or read the container registry images of a project without the need of having a user and a password.
Please note, that the expiration of deploy tokens happens on the date you define,
at midnight UTC and that they can be only managed by [masters](https://docs.gitlab.com/ee/user/permissions.html).
at midnight UTC and that they can be only managed by [maintainers](https://docs.gitlab.com/ee/user/permissions.html).
## Creating a Deploy Token
......
......@@ -2,7 +2,7 @@
You can find the available integrations under your project's
**Settings ➔ Integrations** page. You need to have at least
[master permission][permissions] on the project.
[maintainer permission][permissions] on the project.
## Project services
......
......@@ -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) |
......
......@@ -4,7 +4,7 @@ You can manage the groups and users and their access levels in all of your
projects. You can also personalize the access level you give each user,
per-project.
You should have `master` or `owner` [permissions](../../permissions.md) to add
You should have Maintainer or Owner [permissions](../../permissions.md) to add
or import a new user to your project.
To view, edit, add, and remove project's members, go to your
......@@ -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)
......@@ -99,7 +99,7 @@ side of your screen.
---
Project owners & masters will be notified of your request and will be able to approve or
Project owners & maintainers will be notified of your request and will be able to approve or
decline it on the members page.
![Manage access requests](img/access_requests_management.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,19 +45,19 @@ 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.
For example, you could set "Allowed to push" to "No one", and "Allowed to merge"
to "Developers + Masters", to require _everyone_ to submit a merge request for
to "Developers + Maintainers", to require _everyone_ to submit a merge request for
changes going into the protected branch. This is compatible with workflows like
the [GitLab workflow](../../workflow/gitlab_flow.md).
However, there are workflows where that is not needed, and only protecting from
force pushes and branch removal is useful. For those workflows, you can allow
everyone with write access to push to a protected branch by setting
"Allowed to push" to "Developers + Masters".
"Allowed to push" to "Developers + Maintainers".
You can set the "Allowed to push" and "Allowed to merge" options while creating
a protected branch or afterwards by selecting the option you want from the
......@@ -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
......
......@@ -19,7 +19,7 @@
> - The exports are stored in a temporary [shared directory][tmp] and are deleted
> every 24 hours by a specific worker.
> - Group members will get exported as project members, as long as the user has
> master or admin access to the group where the exported project lives. An admin
> maintainer or admin access to the group where the exported project lives. An admin
> in the import side is required to map the users, based on email or username.
> Otherwise, a supplementary comment is left to mention the original author and
> the MRs, notes or issues will be owned by the importer.
......
# 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
......
......@@ -131,7 +131,7 @@ There is room for more feedback and after the assigned person feels comfortable
If the assigned person does not feel comfortable they can close the merge request without merging.
In GitLab it is common to protect the long-lived branches (e.g. the master branch) so that normal developers [can't modify these protected branches](http://docs.gitlab.com/ce/permissions/permissions.html).
So if you want to merge it into a protected branch you assign it to someone with master authorizations.
So if you want to merge it into a protected branch you assign it to someone with maintainer authorizations.
## Issue tracking with GitLab flow
......
......@@ -144,7 +144,7 @@ git lfs unlock --id=123
```
If for some reason you need to unlock a file that was not locked by you,
you can use the `--force` flag as long as you have a `master` access on
you can use the `--force` flag as long as you have a `maintainer` access on
the project:
```bash
......
......@@ -41,10 +41,10 @@ module API
requires :name, type: String, desc: 'The name of the protected branch'
optional :push_access_level, type: Integer,
values: ProtectedRefAccess::ALLOWED_ACCESS_LEVELS,
desc: 'Access levels allowed to push (defaults: `40`, master access level)'
desc: 'Access levels allowed to push (defaults: `40`, maintainer access level)'
optional :merge_access_level, type: Integer,
values: ProtectedRefAccess::ALLOWED_ACCESS_LEVELS,
desc: 'Access levels allowed to merge (defaults: `40`, master access level)'
desc: 'Access levels allowed to merge (defaults: `40`, maintainer access level)'
end
post ':id/protected_branches' do
protected_branch = user_project.protected_branches.find_by(name: params[:name])
......
......@@ -29,10 +29,10 @@ module Gitlab
def options
{
"Guest" => GUEST,
"Reporter" => REPORTER,
"Developer" => DEVELOPER,
"Master" => MASTER
"Guest" => GUEST,
"Reporter" => REPORTER,
"Developer" => DEVELOPER,
"Maintainer" => MASTER
}
end
......@@ -57,10 +57,10 @@ module Gitlab
def protection_options
{
"Not protected: Both developers and masters can push new commits, force push, or delete the branch." => PROTECTION_NONE,
"Protected against pushes: Developers cannot push new commits, but are allowed to accept merge requests to the branch. Masters can push to the branch." => PROTECTION_DEV_CAN_MERGE,
"Partially protected: Both developers and masters can push new commits, but cannot force push or delete the branch." => PROTECTION_DEV_CAN_PUSH,
"Fully protected: Developers cannot push new commits, but masters can. No-one can force push or delete the branch." => PROTECTION_FULL
"Not protected: Both developers and maintainers can push new commits, force push, or delete the branch." => PROTECTION_NONE,
"Protected against pushes: Developers cannot push new commits, but are allowed to accept merge requests to the branch. Maintainers can push to the branch." => PROTECTION_DEV_CAN_MERGE,
"Partially protected: Both developers and maintainers can push new commits, but cannot force push or delete the branch." => PROTECTION_DEV_CAN_PUSH,
"Fully protected: Developers cannot push new commits, but maintainers can. No-one can force push or delete the branch." => PROTECTION_FULL
}
end
......
......@@ -5,7 +5,7 @@ module Gitlab
push_code: 'You are not allowed to push code to this project.',
delete_default_branch: 'The default branch of a project cannot be deleted.',
force_push_protected_branch: 'You are not allowed to force push code to a protected branch on this project.',
non_master_delete_protected_branch: 'You are not allowed to delete protected branches from this project. Only a project master or owner can delete a protected branch.',
non_master_delete_protected_branch: 'You are not allowed to delete protected branches from this project. Only a project maintainer or owner can delete a protected branch.',
non_web_delete_protected_branch: 'You can only delete protected branches using the web interface.',
merge_protected_branch: 'You are not allowed to merge code into protected branches on this project.',
push_protected_branch: 'You are not allowed to push code to protected branches on this project.',
......
......@@ -439,7 +439,7 @@ msgstr ""
msgid "Artifacts"
msgstr ""
msgid "Ask your group master to setup a group Runner."
msgid "Ask your group maintainer to setup a group Runner."
msgstr ""
msgid "Assign custom color like #FF0000"
......@@ -696,7 +696,7 @@ msgstr ""
msgid "Branches|Once you confirm and press %{delete_protected_branch}, it cannot be undone or recovered."
msgstr ""
msgid "Branches|Only a project master or owner can delete a protected branch"
msgid "Branches|Only a project maintainer or owner can delete a protected branch"
msgstr ""
msgid "Branches|Overview"
......@@ -2237,7 +2237,7 @@ msgstr ""
msgid "Group Runners"
msgstr ""
msgid "Group masters can register group runners in the %{link}"
msgid "Group maintainers can register group runners in the %{link}"
msgstr ""
msgid "GroupSettings|Prevent sharing a project within %{group} with other groups"
......@@ -4764,7 +4764,7 @@ msgstr ""
msgid "You have reached your project limit"
msgstr ""
msgid "You must have master access to force delete a lock"
msgid "You must have maintainer access to force delete a lock"
msgstr ""
msgid "You must sign in to star a project"
......
......@@ -41,7 +41,7 @@ module QA
end
def allow_devs_and_masters_to_push
click_allow(:push, 'Developers + Masters')
click_allow(:push, 'Developers + Maintainers')
end
def allow_no_one_to_merge
......@@ -49,7 +49,7 @@ module QA
end
def allow_devs_and_masters_to_merge
click_allow(:merge, 'Developers + Masters')
click_allow(:merge, 'Developers + Maintainers')
end
def protect_branch
......
......@@ -35,7 +35,7 @@ module QA
end
expect(protected_branch.name).to have_content(branch_name)
expect(protected_branch.push_allowance).to have_content('Developers + Masters')
expect(protected_branch.push_allowance).to have_content('Developers + Maintainers')
end
scenario 'users without authorization cannot push to protected branch' do
......
......@@ -30,7 +30,7 @@ describe 'Projects > Settings > User manages group links' do
click_link('Share with group')
select2(group_market.id, from: '#link_group_id')
select('Master', from: 'link_group_access')
select('Maintainer', from: 'link_group_access')
click_button('Share')
......
......@@ -62,7 +62,7 @@ describe 'Projects > Settings > User manages project members' do
page.within('.project-members-groups') do
expect(page).to have_content('OpenSource')
expect(first('.group_member')).to have_content('Master')
expect(first('.group_member')).to have_content('Maintainer')
end
end
end
......@@ -72,7 +72,7 @@ feature 'Protected Branches', :js do
click_link 'No one'
find(".js-allowed-to-push").click
wait_for_requests
click_link 'Developers + Masters'
click_link 'Developers + Maintainers'
end
visit project_protected_branches_path(project)
......@@ -82,7 +82,7 @@ feature 'Protected Branches', :js do
expect(page.find(".dropdown-toggle-text")).to have_content("No one")
end
page.within(".js-allowed-to-push") do
expect(page.find(".dropdown-toggle-text")).to have_content("Developers + Masters")
expect(page.find(".dropdown-toggle-text")).to have_content("Developers + Maintainers")
end
end
end
......
......@@ -184,7 +184,7 @@ feature 'Runners' do
given(:group) { create :group }
context 'as project and group master' do
context 'as project and group maintainer' do
background do
group.add_master(user)
end
......@@ -197,13 +197,13 @@ feature 'Runners' do
expect(page).to have_content 'This group does not provide any group Runners yet'
expect(page).to have_content 'Group masters can register group runners in the Group CI/CD settings'
expect(page).not_to have_content 'Ask your group master to setup a group Runner'
expect(page).to have_content 'Group maintainers can register group runners in the Group CI/CD settings'
expect(page).not_to have_content 'Ask your group maintainer to setup a group Runner'
end
end
end
context 'as project master' do
context 'as project maintainer' do
context 'project without a group' do
given(:project) { create :project }
......@@ -223,8 +223,8 @@ feature 'Runners' do
expect(page).to have_content 'This group does not provide any group Runners yet.'
expect(page).not_to have_content 'Group masters can register group runners in the Group CI/CD settings'
expect(page).to have_content 'Ask your group master to setup a group Runner.'
expect(page).not_to have_content 'Group maintainers can register group runners in the Group CI/CD settings'
expect(page).to have_content 'Ask your group maintainer to setup a group Runner.'
end
end
......
......@@ -20,7 +20,7 @@ describe('issue_note_actions component', () => {
beforeEach(() => {
props = {
accessLevel: 'Master',
accessLevel: 'Maintainer',
authorId: 26,
canDelete: true,
canEdit: true,
......@@ -67,7 +67,7 @@ describe('issue_note_actions component', () => {
beforeEach(() => {
store.dispatch('setUserData', {});
props = {
accessLevel: 'Master',
accessLevel: 'Maintainer',
authorId: 26,
canDelete: false,
canEdit: false,
......
......@@ -52,7 +52,7 @@ describe Gitlab::Checks::ChangeAccess do
context 'with protected tag' do
let!(:protected_tag) { create(:protected_tag, project: project, name: 'v*') }
context 'as master' do
context 'as maintainer' do
before do
project.add_master(user)
end
......@@ -138,7 +138,7 @@ describe Gitlab::Checks::ChangeAccess do
context 'if the user is not allowed to delete protected branches' do
it 'raises an error' do
expect { subject.exec }.to raise_error(Gitlab::GitAccess::UnauthorizedError, 'You are not allowed to delete protected branches from this project. Only a project master or owner can delete a protected branch.')
expect { subject.exec }.to raise_error(Gitlab::GitAccess::UnauthorizedError, 'You are not allowed to delete protected branches from this project. Only a project maintainer or owner can delete a protected branch.')
end
end
......
......@@ -179,14 +179,14 @@ describe ProjectTeam do
end
describe "#human_max_access" do
it 'returns Master role' do
it 'returns Maintainer role' do
user = create(:user)
group = create(:group)
project = create(:project, namespace: group)
group.add_master(user)
expect(project.team.human_max_access(user.id)).to eq 'Master'
expect(project.team.human_max_access(user.id)).to eq 'Maintainer'
end
it 'returns Owner role' do
......
......@@ -80,12 +80,12 @@ describe Lfs::UnlockFileService do
result = subject.execute
expect(result[:status]).to eq(:error)
expect(result[:message]).to match(/You must have master access/)
expect(result[:message]).to match(/You must have maintainer access/)
expect(result[:http_status]).to eq(403)
end
end
context 'by a master user' do
context 'by a maintainer user' do
let(:current_user) { master }
let(:params) do
{ id: lock.id,
......
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