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
This commit is contained in:
Sean McGivern
commit
e9ad837cf0
58 changed files with 131 additions and 126 deletions
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
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"
|
||||
}
|
||||
]
|
||||
}
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# 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.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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 |
|
||||
| :-----------: | :----------: |
|
||||
|  |  |
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
||||
|
||||
|
|
@ -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.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
|||
|
||||
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
# 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,
|
||||
|
|
|
|||
Loading…
Reference in a new issue