Commit 42805c1b authored by Evan Read's avatar Evan Read

Merge branch 'msj-permission-links' into 'master'

Format user roles notes to reduce extra links

See merge request gitlab-org/gitlab!79421
parents a4374fe9 18bb1f47
......@@ -312,7 +312,7 @@ Example response:
### Retrieve a specific project audit event
Only available to users with at least the [Maintainer role](../user/permissions.md) for the project.
Only available to users with at least the Maintainer role for the project.
```plaintext
GET /projects/:id/audit_events/:audit_event_id
......
......@@ -12,8 +12,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/273655) from GitLab Premium to GitLab Free in 13.6.
Schedules for deletion the cached manifests and blobs for a group. This endpoint requires the
[Owner role](../user/permissions.md)
for the group.
Owner role for the group.
```plaintext
DELETE /groups/:id/dependency_proxy/cache
......
......@@ -49,7 +49,7 @@ Example response:
## Project deploy tokens
Project deploy token API endpoints require the [Maintainer role](../user/permissions.md) or higher
Project deploy token API endpoints require the Maintainer role or higher
for the project.
### List project deploy tokens
......@@ -165,7 +165,7 @@ curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" \
## Group deploy tokens
Users with at least the [Maintainer role](../user/permissions.md) for the group can list group deploy
Users with at least the Maintainer role for the group can list group deploy
tokens. Only group Owners can create and delete group deploy tokens.
### List group deploy tokens
......
......@@ -10,7 +10,7 @@ type: reference, api
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/279039) in GitLab 13.10.
> - The legacy key/value pair `{ "<date>" => "<value>" }` was removed from the payload in GitLab 14.0.
All methods require at least the Reporter [role](../../user/permissions.md).
All methods require at least the Reporter role.
## Get project-level DORA metrics
......
......@@ -11,7 +11,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
## Error Tracking project settings
The project settings API allows you to retrieve the [Error Tracking](../operations/error_tracking.md)
settings for a project. Only for users with [Maintainer role](../user/permissions.md) for the project.
settings for a project. Only for users with Maintainer role for the project.
### Get Error Tracking settings
......@@ -42,7 +42,7 @@ Example response:
### Enable or disable the Error Tracking project settings
The API allows you to enable or disable the Error Tracking settings for a project. Only for users with the
[Maintainer role](../user/permissions.md) for the project.
Maintainer role for the project.
```plaintext
PATCH /projects/:id/error_tracking/settings
......@@ -75,7 +75,7 @@ Example response:
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/68384) in GitLab 14.3.
For [integrated error tracking](https://gitlab.com/gitlab-org/gitlab/-/issues/329596) feature. Only for users with the
[Maintainer role](../user/permissions.md) for the project.
Maintainer role for the project.
### List project client keys
......
......@@ -17,7 +17,7 @@ Similarly to [project-level](../user/project/clusters/index.md) and
group-level Kubernetes clusters allow you to connect a Kubernetes cluster to
your group, enabling you to use the same cluster across multiple projects.
Users need at least the [Maintainer role](../user/permissions.md) for the group to use these endpoints.
Users need at least the Maintainer role for the group to use these endpoints.
## List group clusters
......
......@@ -808,7 +808,7 @@ Parameters:
### Options for `default_branch_protection`
The `default_branch_protection` attribute determines whether users with the Developer or [Maintainer role](../user/permissions.md) can push to the applicable [default branch](../user/project/repository/branches/default.md), as described in the following table:
The `default_branch_protection` attribute determines whether users with the Developer or Maintainer role can push to the applicable [default branch](../user/project/repository/branches/default.md), as described in the following table:
| Value | Description |
|-------|-------------------------------------------------------------------------------------------------------------|
......
......@@ -13,7 +13,7 @@ In GitLab 14.4, the `services` endpoint was [renamed](https://gitlab.com/gitlab-
Calls to the Integrations API can be made to both `/projects/:id/services` and `/projects/:id/integrations`.
The examples in this document refer to the endpoint at `/projects/:id/integrations`.
This API requires an access token with the [Maintainer or Owner role](../user/permissions.md).
This API requires an access token with the Maintainer or Owner role.
## List all active integrations
......
......@@ -12,7 +12,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
WARNING:
This feature was [deprecated](https://gitlab.com/groups/gitlab-org/configure/-/epics/8) in GitLab 14.5.
Users need at least the [Maintainer](../user/permissions.md) role to use these endpoints.
Users need at least the Maintainer role to use these endpoints.
## List project clusters
......
......@@ -246,7 +246,7 @@ curl "https://gitlab.com/api/v4/projects/1/snippets/2/files/master/snippet%2Erb/
## Get user agent details
Available only for users with the Administrator [role](../user/permissions.md).
Available only for users with the Administrator role.
```plaintext
GET /projects/:id/snippets/:snippet_id/user_agent_detail
......
......@@ -1434,7 +1434,7 @@ Supported attributes:
| `request_access_enabled` | boolean | **{dotted-circle}** No | Allow users to request member access. |
| `requirements_access_level` | string | **{dotted-circle}** No | One of `disabled`, `private`, `enabled` or `public` |
| `resolve_outdated_diff_discussions` | boolean | **{dotted-circle}** No | Automatically resolve merge request diffs discussions on lines changed with a push. |
| `restrict_user_defined_variables` | boolean | **{dotted-circle}** No | Allow only users with the [Maintainer role](../user/permissions.md) to pass user-defined variables when triggering a pipeline. For example when the pipeline is triggered in the UI, with the API, or by a trigger token. |
| `restrict_user_defined_variables` | boolean | **{dotted-circle}** No | Allow only users with the Maintainer role to pass user-defined variables when triggering a pipeline. For example when the pipeline is triggered in the UI, with the API, or by a trigger token. |
| `service_desk_enabled` | boolean | **{dotted-circle}** No | Enable or disable Service Desk feature. |
| `shared_runners_enabled` | boolean | **{dotted-circle}** No | Enable shared runners for this project. |
| `show_default_award_emojis` | boolean | **{dotted-circle}** No | Show default award emojis. |
......
......@@ -178,7 +178,7 @@ To view more than the first 20 runners, use [pagination](index.md#pagination).
Get details of a runner.
At least the [Maintainer role](../user/permissions.md) is required to get runner details at the
At least the Maintainer role is required to get runner details at the
project and group level.
Instance-level runner details via this endpoint are available to all signed in users.
......@@ -318,7 +318,7 @@ Pause a specific runner.
```plaintext
PUT --form "paused=true" /runners/:runner_id
# --or--
# --or--
# Deprecated: removal planned in 15.0
PUT --form "active=false" /runners/:runner_id
......
......@@ -13,8 +13,8 @@ Every API call to suggestions must be authenticated.
## Applying suggestions
Applies a suggested patch in a merge request. Users must be
at least [Developer](../user/permissions.md) to perform such action.
Applies a suggested patch in a merge request. Users must have
at least the Developer role to perform such action.
```plaintext
PUT /suggestions/:id/apply
......
......@@ -43,7 +43,7 @@ job completes:
[Slack API](https://api.slack.com/) to send data to the channel.
To use the `run` command, you must have at least the
[Developer role](../../user/permissions.md#project-members-permissions).
Developer role.
If a job shouldn't be able to be triggered from chat, you can set the job to `except: [chat]`.
## Best practices for ChatOps CI jobs
......@@ -55,7 +55,7 @@ functions available. Consider these best practices when creating ChatOps jobs:
of the standard CI pipeline.
- If the job is set to `when: manual`, ChatOps creates the pipeline, but the job waits to be started.
- ChatOps provides limited support for access control. If the user triggering the
slash command has at least the [Developer role](../../user/permissions.md#project-members-permissions)
slash command has at least the Developer role
in the project, the job runs. The job itself can use existing
[CI/CD variables](../variables/index.md#predefined-cicd-variables) like
`GITLAB_USER_ID` to perform additional rights validation, but
......
......@@ -49,10 +49,10 @@ Example:
name: ${CI_JOB_NAME}
```
### Require approvals for a protected environment
### Require approvals for a protected environment
NOTE:
At this time, only API-based configuration is available. UI-based configuration is planned for the near future. See [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/344675).
At this time, only API-based configuration is available. UI-based configuration is planned for the near future. See [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/344675).
Use the [Protected Environments API](../../api/protected_environments.md#protect-repository-environments) to create an environment with `required_approval_count` > 0. After this is set, all jobs deploying to this environment automatically go into a blocked state and wait for approvals before running.
......@@ -66,7 +66,7 @@ curl --header 'Content-Type: application/json' --request POST \
```
To protect, update, or unprotect an environment, you must have at least the
[Maintainer role](../../user/permissions.md).
Maintainer role.
## Approve or reject a deployment
......@@ -75,7 +75,7 @@ This functionality is currently only available through the API. UI is planned fo
A blocked deployment is enqueued as soon as it receives the required number of approvals. A single rejection causes the deployment to fail. The creator of a deployment cannot approve it, even if they have permission to deploy.
Using the [Deployments API](../../api/deployments.md#approve-or-reject-a-blocked-deployment), users who are allowed to deploy to the protected environment can approve or reject a blocked deployment.
Using the [Deployments API](../../api/deployments.md#approve-or-reject-a-blocked-deployment), users who are allowed to deploy to the protected environment can approve or reject a blocked deployment.
Example:
......@@ -95,7 +95,7 @@ curl --data "status=approved" \
#### Using the API
Use the [Deployments API](../../api/deployments.md) to see deployments. The `status` field indicates if a deployment is blocked.
Use the [Deployments API](../../api/deployments.md) to see deployments. The `status` field indicates if a deployment is blocked.
## Related features
......
......@@ -26,7 +26,7 @@ If you are using a continuous deployment workflow and want to ensure that concur
## Restrict write access to a critical environment
By default, environments can be modified by any team member that has at least the
[Developer role](../../user/permissions.md#project-members-permissions).
Developer role.
If you want to restrict write access to a critical environment (for example a `production` environment),
you can set up [protected environments](protected_environments.md).
......@@ -93,7 +93,7 @@ If you want to prevent deployments for a particular period, for example during a
vacation period when most employees are out, you can set up a [Deploy Freeze](../../user/project/releases/index.md#prevent-unintentional-releases-by-setting-a-deploy-freeze).
During a deploy freeze period, no deployment can be executed. This is helpful to
ensure that deployments do not happen unexpectedly.
## Setting appropriate roles to your project
GitLab supports several different roles that can be assigned to your project members. See
......@@ -119,7 +119,7 @@ The other pipelines don't get the protected variable. You can also
We recommend that you use protected variables on protected environments to make sure that the
secrets aren't exposed unintentionally. You can also define production secrets on the
[runner side](../runners/configure_runners.md#prevent-runners-from-revealing-sensitive-information).
This prevents other users with the [Maintainer role](../../user/permissions.md) from reading the secrets and makes sure
This prevents other users with the Maintainer role from reading the secrets and makes sure
that the runner only runs on protected branches.
For more information, see [pipeline security](../pipelines/index.md#pipeline-security-on-protected-branches).
......
......@@ -27,7 +27,7 @@ You can even access a [web terminal](#web-terminals-deprecated) for your environ
Prerequisites:
- You must have at least the Reporter [role](../../user/permissions.md#project-members-permissions).
- You must have at least the Reporter role.
To view a list of environments and deployments:
......@@ -313,7 +313,7 @@ Note the following:
deleted. For more information, see [Ref Specs for Runners](../pipelines/index.md#ref-specs-for-runners).
NOTE:
For Windows runners, using `echo` to write to `.env` files may fail. Using the PowerShell `Add-Content`command
For Windows runners, using `echo` to write to `.env` files may fail. Using the PowerShell `Add-Content`command
will help in such cases. For example:
```powershell
......
......@@ -20,7 +20,7 @@ NOTE:
GitLab administrators can use all environments, including protected environments.
To protect, update, or unprotect an environment, you need to have at least the
[Maintainer role](../../user/permissions.md).
Maintainer role.
## Protecting environments
......@@ -103,12 +103,12 @@ The group now has access and can be seen in the UI.
## Environment access by group membership
A user may be granted access to protected environments as part of [group membership](../../user/group/index.md). Users
with the Reporter [role](../../user/permissions.md) can only be granted access to protected environments with this
with the Reporter role can only be granted access to protected environments with this
method.
## Deployment branch access
Users with the [Developer role](../../user/permissions.md) can be granted
Users with the Developer role can be granted
access to a protected environment through any of these methods:
- As an individual contributor, through a role.
......@@ -125,7 +125,7 @@ they have the following privileges:
Users granted access to a protected environment, but not push or merge access
to the branch deployed to it, are only granted access to deploy the environment. An individual in a
group with the Reporter [role](../../user/permissions.md), or in groups added to the project with the Reporter
group with the Reporter role, or in groups added to the project with the Reporter
role, appears in the dropdown menu for deployment-only access.
To add deployment-only access:
......@@ -136,7 +136,7 @@ To add deployment-only access:
1. Follow the steps in [Protecting Environments](#protecting-environments).
Note that deployment-only access is the only possible access level for groups with the Reporter
[role](../../user/permissions.md).
role.
## Modifying and unprotecting environments
......@@ -194,14 +194,14 @@ and are protected at the same time.
In an enterprise organization, with thousands of projects under a single group,
ensuring that all of the [project-level protected environments](#protecting-environments)
are properly configured is not a scalable solution. For example, a developer
might gain privileged access to a higher environment when they are given the [Maintainer role](../../user/permissions.md)
might gain privileged access to a higher environment when they are given the Maintainer role
for a new project. Group-level protected environments can be a solution in this situation.
To maximize the effectiveness of group-level protected environments,
[group-level memberships](../../user/group/index.md) must be correctly
configured:
- Operators should be given at least the [Maintainer role](../../user/permissions.md)
- Operators should be given at least the Maintainer role
for the top-level group. They can maintain CI/CD configurations for
the higher environments (such as production) in the group-level settings page,
which includes group-level protected environments,
......@@ -210,8 +210,8 @@ configured:
configurations are inherited to the child projects as read-only entries.
This ensures that only operators can configure the organization-wide
deployment ruleset.
- Developers should be given no more than the [Developer role](../../user/permissions.md)
for the top-level group, or explicitly given the [Maintainer role](../../user/permissions.md) for a child project
- Developers should be given no more than the Developer role
for the top-level group, or explicitly given the Maintainer role for a child project
They do *NOT* have access to the CI/CD configurations in the
top-level group, so operators can ensure that the critical configuration won't
be accidentally changed by the developers.
......@@ -224,7 +224,7 @@ configured:
environment configurations exist, to run a deployment job, the user must be allowed in **both**
rulesets.
- In a project or a subgroup of the top-level group, developers can be
safely assigned the [Maintainer role](../../user/permissions.md) to tune their lower environments (such
safely assigned the Maintainer role to tune their lower environments (such
as `testing`).
Having this configuration in place:
......
......@@ -94,7 +94,7 @@ The job token scope is only for controlling access to private projects.
1. Expand **Token Access**.
1. Toggle **Limit CI_JOB_TOKEN access** to enabled.
1. Optional. Add existing projects to the token's access scope. The user adding a
project must have the [maintainer role](../../user/permissions.md) in both projects.
project must have the Maintainer role in both projects.
There is [a proposal](https://gitlab.com/groups/gitlab-org/-/epics/3559) to improve
the feature with more strategic control of the access permissions.
......
......@@ -281,7 +281,7 @@ pipelines.
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/24851) in GitLab 12.7.
Users with the [Owner role](../../user/permissions.md) in a project can delete a pipeline
Users with the Owner role for a project can delete a pipeline
by clicking on the pipeline in the **CI/CD > Pipelines** to get to the **Pipeline Details**
page, then using the **Delete** button.
......
......@@ -259,7 +259,7 @@ You can delete a single job, which also removes the job's
artifacts and log. You must be:
- The owner of the job.
- A [maintainer](../../user/permissions.md#gitlab-cicd-permissions) of the project.
- A Maintainer of the project.
To delete a job:
......@@ -381,7 +381,7 @@ to the `expire_in` specification.
If a new pipeline for the same ref completes successfully, the previous pipeline's
artifacts are deleted according to the `expire_in` configuration. The artifacts
of the new pipeline are kept automatically.
of the new pipeline are kept automatically.
Keeping the latest artifacts can use a large amount of storage space in projects
with a lot of jobs or large artifacts. If the latest artifacts are not needed in
......
......@@ -58,7 +58,7 @@ To use merge request pipelines:
jobs that run in merge request pipelines. To do this, you can use:
- [`rules`](#use-rules-to-add-jobs).
- [`only/except`](#use-only-to-add-jobs).
- You must have at least the Developer [role](../../user/permissions.md) in the
- You must have at least the Developer role in the
source project to run a merge request pipeline.
- Your repository must be a GitLab repository, not an [external repository](../ci_cd_for_external_repos/index.md).
......@@ -142,7 +142,7 @@ parent project when the pipeline runs, even before merge. As a reviewer, careful
check the changes in the merge request before triggering the pipeline. GitLab shows
a warning that you must accept before you can trigger the pipeline.
Parent project members with at least the [Developer role](../../user/permissions.md)
Parent project members with at least the Developer role
can create pipelines in the parent project for merge requests from a forked project:
1. In the merge request, go to the **Pipelines** tab.
......
......@@ -67,7 +67,7 @@ branch](https://www.youtube.com/watch?v=D4qCqXgZkHQ).
To enable merge trains:
- You must have the [Maintainer role](../../user/permissions.md).
- You must have the Maintainer role.
- You must be using [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner) 11.9 or later.
- In GitLab 13.0 and later, you need [Redis](https://redis.io/) 5.0 or later.
- Your repository must be a GitLab repository, not an
......
......@@ -40,7 +40,7 @@ To use merged results pipelines:
## Enable merged results pipelines
To enable merged results pipelines in a project, you must have at least the
[Maintainer role](../../user/permissions.md):
Maintainer role:
1. On the top bar, select **Menu > Projects** and find your project.
1. On the left sidebar, select **Settings > General**.
......
......@@ -283,7 +283,7 @@ tag in a different project.
Prerequisites:
- The upstream project must be [public](../../public_access/public_access.md).
- The user must have the [Developer role](../../user/permissions.md#project-members-permissions)
- The user must have the Developer role
in the upstream project.
To trigger the pipeline when the upstream project is rebuilt:
......
......@@ -12,7 +12,7 @@ Use this document to get started with [GitLab CI/CD](../index.md).
Before you start, make sure you have:
- A project in GitLab that you would like to use CI/CD for.
- The [Maintainer or Owner role](../../user/permissions.md) for the project.
- The Maintainer or Owner role for the project.
If you are migrating from another CI/CD tool, view this documentation:
......
......@@ -58,7 +58,7 @@ can still run `build` jobs concurrently for maximizing the pipeline efficiency.
- The basic knowledge of the [GitLab CI/CD pipelines](../pipelines/index.md)
- The basic knowledge of the [GitLab Environments and Deployments](../environments/index.md)
- [Developer role](../../user/permissions.md) (or above) in the project to configure CI/CD pipelines.
- At least the Developer role for the project to configure CI/CD pipelines.
### Limitations
......
......@@ -73,7 +73,7 @@ you can copy and paste into `.gitlab-ci.yml` as a starting point.
Prerequisite:
- You need at least the Developer [role](../../user/permissions.md) for the project.
- You need at least the Developer role for the project.
To use the Review Apps template:
......
......@@ -160,7 +160,7 @@ the GitLab instance. To determine this:
### Determine the IP address of a specific runner
To can find the IP address of a runner for a specific project,
you must have the [Owner role](../../user/permissions.md#project-members-permissions) for the
you must have the Owner role for the
project.
1. Go to the project's **Settings > CI/CD** and expand the **Runners** section.
......@@ -187,7 +187,7 @@ the appropriate dependencies to run Rails test suites.
When you [register a runner](https://docs.gitlab.com/runner/register/), its default behavior is to **only pick**
[tagged jobs](../yaml/index.md#tags).
To change this, you must have the [Owner role](../../user/permissions.md#project-members-permissions) for the project.
To change this, you must have the Owner role for the project.
To make a runner pick untagged jobs:
......
......@@ -55,7 +55,7 @@ To enable shared runners:
### Disable shared runners
You can disable shared runners for individual projects or for groups.
You must have the [Owner role](../../user/permissions.md#group-members-permissions) for the project
You must have the Owner role for the project
or group.
To disable shared runners for a project:
......@@ -144,7 +144,7 @@ Group runners process jobs by using a first in, first out ([FIFO](https://en.wik
### Create a group runner
You can create a group runner for your self-managed GitLab instance or for GitLab.com.
You must have the [Owner role](../../user/permissions.md#group-members-permissions) for the group.
You must have the Owner role for the group.
To create a group runner:
......@@ -160,7 +160,7 @@ To create a group runner:
You can view and manage all runners for a group, its subgroups, and projects.
You can do this for your self-managed GitLab instance or for GitLab.com.
You must have the [Owner role](../../user/permissions.md#group-members-permissions) for the group.
You must have the Owner role for the group.
1. Go to the group where you want to view the runners.
1. Go to **Settings > CI/CD** and expand the **Runners** section.
......@@ -183,7 +183,7 @@ From this page, you can edit, pause, and remove runners from the group, its subg
### Pause or remove a group runner
You can pause or remove a group runner for your self-managed GitLab instance or for GitLab.com.
You must have the [Owner role](../../user/permissions.md#group-members-permissions) for the group.
You must have the Owner role for the group.
1. Go to the group you want to remove or pause the runner for.
1. Go to **Settings > CI/CD** and expand the **Runners** section.
......@@ -213,7 +213,7 @@ A fork *does* copy the CI/CD settings of the cloned repository.
### Create a specific runner
You can create a specific runner for your self-managed GitLab instance or for GitLab.com.
You must have the [Owner role](../../user/permissions.md#project-members-permissions) for the project.
You must have the Owner role for the project.
To create a specific runner:
......@@ -227,7 +227,7 @@ To create a specific runner:
A specific runner is available in the project it was created for. An administrator can
enable a specific runner to apply to additional projects.
- You must have the [Owner role](../../user/permissions.md#group-members-permissions) for the
- You must have the Owner role for the
project.
- The specific runner must not be [locked](#prevent-a-specific-runner-from-being-enabled-for-other-projects).
......
......@@ -20,7 +20,7 @@ use external test planning tools, which require additional overhead, context swi
Prerequisite:
- You must have at least the Reporter [role](../../user/permissions.md).
- You must have at least the Reporter role.
To create a test case in a GitLab project:
......@@ -36,7 +36,7 @@ issue list with a search query, including labels or the test case's title.
Prerequisite:
- You must have at least the Guest [role](../../user/permissions.md).
- You must have at least the Guest role.
To view a test case:
......@@ -51,7 +51,7 @@ You can edit a test case's title and description.
Prerequisite:
- You must have at least the Reporter [role](../../user/permissions.md).
- You must have at least the Reporter role.
- Users demoted to the Guest role can continue to edit the test cases they created
when they were in the higher role.
......@@ -68,7 +68,7 @@ When you want to stop using a test case, you can archive it. You can [reopen an
Prerequisite:
- You must have at least the Reporter [role](../../user/permissions.md).
- You must have at least the Reporter role.
To archive a test case, on the test case's page, select the **Archive test case** button.
......@@ -81,6 +81,6 @@ To view archived test cases:
If you decide to start using an archived test case again, you can reopen it.
You must have at least the Reporter [role](../../user/permissions.md).
You must have at least the Reporter role.
To reopen an archived test case, on the test case's page, select **Reopen test case**.
......@@ -22,7 +22,7 @@ to authenticate an API call. The token impersonates a user's project access and
Prerequisite:
- You must have at least the [Maintainer role](../../user/permissions.md) for the project.
- You must have at least the Maintainer role for the project.
To create a trigger token:
......
......@@ -154,7 +154,7 @@ job:
### Add a CI/CD variable to a project
You can add CI/CD variables to a project's settings. Only project members with the
[Maintainer role](../../user/permissions.md#project-members-permissions)
Maintainer role
can add or update project CI/CD variables. To keep a CI/CD variable secret, put it
in the project settings, not in the `.gitlab-ci.yml` file.
......@@ -233,7 +233,7 @@ inherited.
> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/299879) in GitLab 13.11.
To make a CI/CD variable available to all projects and groups in a GitLab instance,
add an instance CI/CD variable. You must have the [Administrator role](../../user/permissions.md).
add an instance CI/CD variable. You must have the Administrator access level.
You can define instance variables via the UI or [API](../../api/instance_level_ci_variables.md).
......@@ -900,7 +900,7 @@ if [[ -d "/builds/gitlab-examples/ci-debug-trace/.git" ]]; then
> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/292661) in GitLab 13.8.
You can restrict access to debug logging. When restricted, only users with
[developer or higher permissions](../../user/permissions.md#project-members-permissions)
at least the Developer role
can view job logs when debug logging is enabled with a variable in:
- The [`.gitlab-ci.yml` file](#create-a-custom-cicd-variable-in-the-gitlab-ciyml-file).
......
......@@ -79,7 +79,7 @@ A member of the Technical Writing team adds these labels:
### Reviewing and merging
Anyone with the [Maintainer role](../../user/permissions.md) to the relevant GitLab project can
Anyone with the Maintainer role to the relevant GitLab project can
merge documentation changes. Maintainers must make a good-faith effort to ensure that the content:
- Is clear and sufficiently easy for the intended audience to navigate and understand.
......
......@@ -111,7 +111,7 @@ Each line represents a rule that was evaluated. There are a few things to note:
Here you can see that the first four rules were evaluated `false` for
which user and subject. For example, you can see in the last line that
the rule was activated because the user `john` had the Reporter [role](../user/permissions.md) on
the rule was activated because the user `john` had the Reporter role on
`Project/4`.
When a policy is asked whether a particular ability is allowed
......
......@@ -101,7 +101,7 @@ This is due to technical limitations in the GitLab permission model: the ability
against a protected branch is controlled by the ability to push/merge to this branch.
This means that for developers to be able to trigger a pipeline for the default branch in
`gitlab-org/omnibus-gitlab`/`gitlab-org/gitlab-qa`, they would need to have the
[Maintainer role](../../../user/permissions.md) for those projects.
Maintainer role for those projects.
For security reasons and implications, we couldn't open up the default branch to all the Developers.
Hence we created these mirrors where Developers and Maintainers are allowed to push/merge to the default branch.
This problem was discovered in <https://gitlab.com/gitlab-org/gitlab-qa/-/issues/63#note_107175160> and the "mirror"
......
......@@ -26,7 +26,7 @@ project, group, or instance level:
Copy this value, as you need it in a later step.
1. *For project-level or group-level integrations:* In GitLab, go to your project or group.
1. *For instance-level integrations:*
1. Sign in to GitLab as a user with the [Administrator role](../user/permissions.md).
1. Sign in to GitLab as a user with the Administrator access level.
1. On the top bar, select **Menu > Admin**.
1. On the left sidebar, select **Settings > Integrations**.
1. Scroll to **Add an integration**, and select **Datadog**.
......
......@@ -23,7 +23,7 @@ We recommend the GitLab.com for Jira Cloud app, because data is
synchronized in real time. The DVCS connector updates data only once per hour.
The user configuring the GitLab.com for Jira Cloud app must have
at least the [Maintainer](../../user/permissions.md) role in the GitLab.com namespace.
at least the Maintainer role in the GitLab.com namespace.
This integration method supports [Smart Commits](dvcs.md#smart-commits).
......@@ -43,7 +43,7 @@ To install the GitLab.com for Jira Cloud app:
![Start GitLab.com app configuration on Jira Cloud](img/jira_dev_panel_setup_com_2.png)
1. If not already signed in to GitLab.com, you must sign in as a user with
[Maintainer](../../user/permissions.md) permissions to add namespaces.
the Maintainer role to add namespaces.
![Sign in to GitLab.com in GitLab.com for Jira Cloud app](img/jira_dev_panel_setup_com_3_v13_9.png)
1. To open the list of available namespaces, select **Add namespace**.
......
......@@ -10,7 +10,7 @@ Alerts are a critical entity in your incident management workflow. They represen
## Alert List
Users with at least the Developer [role](../../user/permissions.md) can
Users with at least the Developer role can
access the Alert list at **Monitor > Alerts** in your project's
sidebar. The Alert list displays alerts sorted by start time, but
you can change the sort order by clicking the headers in the Alert list.
......@@ -68,7 +68,7 @@ Alerts contain one of the following icons:
## Alert details page
Navigate to the Alert details view by visiting the [Alert list](alerts.md)
and selecting an alert from the list. You need at least the Developer [role](../../user/permissions.md)
and selecting an alert from the list. You need at least the Developer role
to access alerts.
NOTE:
......@@ -96,7 +96,7 @@ instance.
Prerequisite:
- You must have at least the Developer [role](../../user/permissions.md).
- You must have at least the Developer role.
To view the metrics for an alert:
......@@ -120,7 +120,7 @@ your application's performance and how to resolve any problems.
Prerequisite:
- You must have at least the Developer [role](../../user/permissions.md).
- You must have at least the Developer role.
To view the logs for an alert:
......
......@@ -17,7 +17,7 @@ where you manage [On-call schedules](oncall_schedules.md).
Prerequisite:
- You must have at least the Maintainer [role](../../user/permissions.md).
- You must have at least the Maintainer role.
- You must have an [on-call schedule](oncall_schedules.md).
To create an escalation policy:
......
......@@ -47,7 +47,7 @@ To create an incident from the Issues List:
### Create incidents automatically **(ULTIMATE)**
With at least the Maintainer [role](../../user/permissions.md), you can enable
With at least the Maintainer role, you can enable
GitLab to create incident automatically whenever an alert is triggered:
1. Navigate to **Settings > Monitor > Incidents** and expand **Incidents**.
......@@ -55,7 +55,7 @@ With at least the Maintainer [role](../../user/permissions.md), you can enable
1. To customize the incident, select an
[issue template](../../user/project/description_templates.md#create-an-issue-template).
1. To send [an email notification](paging.md#email-notifications) to users
with the Developer [role](../../user/permissions.md), select
with the Developer role, select
**Send a separate email notification to Developers**. Email notifications are
also sent to users with the **Maintainer** and **Owner** roles.
1. Click **Save changes**.
......@@ -68,7 +68,7 @@ You can set up a webhook with PagerDuty to automatically create a GitLab inciden
for each PagerDuty incident. This configuration requires you to make changes
in both PagerDuty and GitLab:
1. Sign in as a user with the Maintainer [role](../../user/permissions.md).
1. Sign in as a user with the Maintainer role.
1. Navigate to **Settings > Monitor > Incidents** and expand **Incidents**.
1. Select the **PagerDuty integration** tab:
......@@ -276,7 +276,7 @@ templates.
> - [Introduced for Prometheus Integrations](https://gitlab.com/gitlab-org/gitlab/-/issues/13401) in GitLab 12.5.
> - [Introduced for HTTP Integrations](https://gitlab.com/gitlab-org/gitlab/-/issues/13402) in GitLab 13.4.
With at least the Maintainer [role](../../user/permissions.md), you can enable
With at least the Maintainer role, you can enable
GitLab to close an incident automatically when a **Recovery Alert** is received:
1. Navigate to **Settings > Monitor > Incidents** and expand **Incidents**.
......
......@@ -18,7 +18,7 @@ to use this endpoint.
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/245331) in GitLab 13.5.
With at least the Maintainer [role](../../user/permissions.md), you can view the list of configured
With at least the Maintainer role, you can view the list of configured
alerts integrations by navigating to **Settings > Monitor**
in your project's sidebar menu, and expanding the **Alerts** section. The list displays
the integration name, type, and status (enabled or disabled):
......@@ -36,7 +36,7 @@ Enabling the HTTP Endpoint in a GitLab projects activates it to
receive alert payloads in JSON format. You can always
[customize the payload](#customize-the-alert-payload-outside-of-gitlab) to your liking.
1. Sign in to GitLab as a user with the Maintainer [role](../../user/permissions.md)
1. Sign in to GitLab as a user with the Maintainer role
for a project.
1. Navigate to **Settings > Monitor** in your project.
1. Expand the **Alerts** section, and in the **Select integration type** dropdown menu,
......@@ -53,7 +53,7 @@ In [GitLab Premium](https://about.gitlab.com/pricing/), you can create multiple
unique HTTP endpoints to receive alerts from any external source in JSON format,
and you can [customize the payload](#customize-the-alert-payload-outside-of-gitlab).
1. Sign in to GitLab as a user with the Maintainer [role](../../user/permissions.md)
1. Sign in to GitLab as a user with the Maintainer role
for a project.
1. Navigate to **Settings > Monitor** in your project.
1. Expand the **Alerts** section.
......@@ -225,7 +225,7 @@ After a [project maintainer or owner](../../user/permissions.md)
configures an integration, you can trigger a test
alert to confirm your integration works properly.
1. Sign in as a user with at least the Developer [role](../../user/permissions.md).
1. Sign in as a user with at least the Developer role.
1. Navigate to **Settings > Monitor** in your project.
1. Click **Alerts** to expand the section.
1. Click the **{settings}** settings icon on the right side of the integration in [the list](#integrations-list).
......@@ -279,7 +279,7 @@ active at the same time.
To enable Opsgenie integration:
1. Sign in as a user with the Maintainer or Owner [role](../../user/permissions.md).
1. Sign in as a user with the Maintainer or Owner role.
1. Navigate to **Monitor > Alerts**.
1. In the **Integrations** select box, select **Opsgenie**.
1. Select the **Active** toggle.
......
......@@ -24,7 +24,7 @@ Set up an on-call schedule for your team to add rotations to.
Prerequisite:
- You must have at least the Maintainer [role](../../user/permissions.md).
- You must have at least the Maintainer role.
To create an on-call schedule:
......
......@@ -41,7 +41,7 @@ Only AWS S3 is supported as a deploy target.
Prerequisite:
- You must have at least the Maintainer [role](../../user/permissions.md).
- You must have at least the Maintainer role.
To provide GitLab with the AWS account information needed to push content to your Status Page:
......
......@@ -99,8 +99,7 @@ GitLab tags each incident issue with the `incident` label automatically. If the
does not yet exist, it is also created automatically.
If the metric exceeds the threshold of the alert for over 5 minutes, GitLab sends
an email to all [Maintainers and Owners](../../user/permissions.md#project-members-permissions)
of the project.
an email to all Maintainers and Owners of the project.
### Recovery alerts
......
......@@ -53,7 +53,7 @@ The following requirements must be met for the metric to unfurl:
- The `<environment_id>` must correspond to a real environment.
- Prometheus must be monitoring the environment.
- The GitLab instance must be configured to receive data from the environment.
- The user must be allowed access to the monitoring dashboard for the environment ([Reporter or higher](../../user/permissions.md)).
- The user must have at least the Reporter role for the monitoring dashboard for the environment.
- The dashboard must have data within the last 8 hours.
If all of the above are true, then the metric unfurls as seen below:
......
......@@ -50,7 +50,7 @@ Feature.disable(:product_analytics, Project.find(<project ID>))
After enabling the feature flag for Product Analytics, you can access the
user interface:
1. Sign in to GitLab as a user with at least the Reporter [role](../user/permissions.md).
1. Sign in to GitLab as a user with at least the Reporter role.
1. Navigate to **Monitor > Product Analytics**.
The user interface contains:
......
......@@ -7,7 +7,7 @@ type: reference
# Project and group visibility **(FREE)**
GitLab allows users with the Owner [role](../user/permissions.md) to set a project's or group's visibility as:
GitLab allows users with the Owner role to set a project's or group's visibility as:
- **Public**
- **Internal**
......@@ -24,7 +24,7 @@ Public projects can be cloned **without any** authentication over HTTPS.
They are listed in the public access directory (`/public`) for all users.
**Any signed-in user** has the Guest [role](../user/permissions.md) on the repository.
**Any signed-in user** has the Guest role on the repository.
NOTE:
By default, `/public` is visible to unauthenticated users. However, if the
......@@ -39,7 +39,7 @@ Internal projects can be cloned by any signed-in user except
They are also listed in the public access directory (`/public`), but only for signed-in users.
Any signed-in users except [external users](../user/permissions.md#external-users) have the
Guest [role](../user/permissions.md) on the repository.
Guest role on the repository.
NOTE:
From July 2019, the `Internal` visibility setting is disabled for new projects, groups,
......@@ -57,7 +57,7 @@ They appear in the public access directory (`/public`) for project members only.
Prerequisite:
- You must have the Owner [role](../user/permissions.md) for a project.
- You must have the Owner role for a project.
1. On the top bar, select **Menu > Projects** and find your project.
1. On the left sidebar, select **Settings > General**.
......@@ -69,7 +69,7 @@ Prerequisite:
Prerequisite:
- You must have the Owner [role](../user/permissions.md) for a group.
- You must have the Owner role for a group.
1. On the top bar, select **Menu > Groups** and find your project.
1. On the left sidebar, select **Settings > General**.
......
......@@ -14,7 +14,7 @@ You don't need to install anything to use GitLab SaaS, you only need to
- [A subscription](https://about.gitlab.com/pricing/).
- [The number of seats you want](#how-seat-usage-is-determined).
The subscription determines which features are available for your private projects. Organizations with public open source projects can actively apply to our [GitLab for Open Source Program](https://about.gitlab.com/solutions/open-source/join/).
The subscription determines which features are available for your private projects. Organizations with public open source projects can actively apply to our [GitLab for Open Source Program](https://about.gitlab.com/solutions/open-source/join/).
Qualifying open source projects also get 50,000 CI/CD minutes and free access to the **Ultimate** tier
through the [GitLab for Open Source program](https://about.gitlab.com/solutions/open-source/).
......@@ -44,7 +44,7 @@ To subscribe to GitLab SaaS:
Prerequisite:
- You must have the Owner [role](../../user/permissions.md) for the group.
- You must have the Owner role for the group.
To see the status of your GitLab SaaS subscription:
......
......@@ -150,7 +150,7 @@ To change the namespace linked to a subscription:
1. Navigate to the **Manage Purchases** page.
1. Select **Change linked namespace**.
1. Select the desired group from the **This subscription is for** dropdown. For a group to appear
here, you must have the Owner [role](../user/permissions.md)
here, you must have the Owner role
for that group.
1. Select **Proceed to checkout**.
......
......@@ -46,7 +46,7 @@ Before beginning, make sure:
To follow this tutorial, you need:
- The [Maintainer role](../../../user/permissions.md) for the existing Git repository
- The Maintainer role for the existing Git repository
you'd like to migrate to LFS with access through the command line.
- [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)
and [Java Runtime Environment](https://www.java.com/en/download/manual.jsp)
......
......@@ -221,7 +221,7 @@ If the assigned person does not feel comfortable, they can request more changes
In GitLab, it is common to protect the long-lived branches, such as the `main` branch, so [most developers can't modify them](../user/permissions.md).
So, if you want to merge into a protected branch, assign your merge request to someone with the
[Maintainer role](../user/permissions.md).
Maintainer role.
After you merge a feature branch, you should remove it from the source control software.
In GitLab, you can do this when merging.
......
......@@ -7,12 +7,12 @@ type: reference
# Control access and visibility **(FREE SELF)**
GitLab enables users with the [Administrator role](../../permissions.md) to enforce
GitLab enables users with the Administrator access level to enforce
specific controls on branches, projects, snippets, groups, and more.
To access the visibility and access control options:
1. Sign in to GitLab as a user with [Administrator role](../../permissions.md).
1. Sign in to GitLab as a user with Administrator access level.
1. On the top bar, select **Menu > Admin**.
1. On the left sidebar, select **Settings > General**.
1. Expand the **Visibility and access controls** section.
......@@ -29,7 +29,7 @@ or configure [branch protection for groups](../../group/index.md#change-the-defa
To change the default branch protection for the entire instance:
1. Sign in to GitLab as a user with [Administrator role](../../permissions.md).
1. Sign in to GitLab as a user with Administrator access level.
1. On the top bar, select **Menu > Admin**.
1. On the left sidebar, select **Settings > General**.
1. Expand the **Visibility and access controls** section.
......@@ -55,7 +55,7 @@ can be overridden on a per-group basis by the group's owner. In
[GitLab Premium or higher](https://about.gitlab.com/pricing/), GitLab administrators can
disable this privilege for group owners, enforcing the instance-level protection rule:
1. Sign in to GitLab as a user with [Administrator role](../../permissions.md).
1. Sign in to GitLab as a user with Administrator access level.
1. On the top bar, select **Menu > Admin**.
1. On the left sidebar, select **Settings > General**.
1. Expand the **Visibility and access controls** section.
......@@ -71,7 +71,7 @@ Instance-level protections for project creation define which roles can
[add projects to a group](../../group/index.md#specify-who-can-add-projects-to-a-group)
on the instance. To alter which roles have permission to create projects:
1. Sign in to GitLab as a user with [Administrator role](../../permissions.md).
1. Sign in to GitLab as a user with Administrator access level.
1. On the top bar, select **Menu > Admin**.
1. On the left sidebar, select **Settings > General**.
1. Expand the **Visibility and access controls** section.
......@@ -86,7 +86,7 @@ on the instance. To alter which roles have permission to create projects:
Anyone with the **Owner** role, either at the project or group level, can
delete a project. To allow only users with the Administrator role to delete projects:
1. Sign in to GitLab as a user with [Administrator role](../../permissions.md).
1. Sign in to GitLab as a user with Administrator access level.
1. On the top bar, select **Menu > Admin**.
1. On the left sidebar, select **Settings > General**.
1. Expand the **Visibility and access controls** section.
......@@ -137,7 +137,7 @@ Alternatively, projects that are marked for removal can be deleted immediately.
To set the default [visibility levels for new projects](../../../public_access/public_access.md):
1. Sign in to GitLab as a user with [Administrator role](../../permissions.md).
1. Sign in to GitLab as a user with Administrator access level.
1. On the top bar, select **Menu > Admin**.
1. On the left sidebar, select **Settings > General**.
1. Expand the **Visibility and access controls** section.
......@@ -152,7 +152,7 @@ To set the default [visibility levels for new projects](../../../public_access/p
To set the default visibility levels for new [snippets](../../snippets.md):
1. Sign in to GitLab as a user with [Administrator role](../../permissions.md).
1. Sign in to GitLab as a user with Administrator access level.
1. On the top bar, select **Menu > Admin**.
1. On the left sidebar, select **Settings > General**.
1. Expand the **Visibility and access controls** section.
......@@ -166,7 +166,7 @@ For more details on snippet visibility, read
To set the default visibility levels for new groups:
1. Sign in to GitLab as a user with [Administrator role](../../permissions.md).
1. Sign in to GitLab as a user with Administrator access level.
1. On the top bar, select **Menu > Admin**.
1. On the left sidebar, select **Settings > General**.
1. Expand the **Visibility and access controls** section.
......@@ -183,7 +183,7 @@ For more details on group visibility, see
To restrict visibility levels for projects, snippets, and selected pages:
1. Sign in to GitLab as a user with [Administrator role](../../permissions.md).
1. Sign in to GitLab as a user with Administrator access level.
1. On the top bar, select **Menu > Admin**.
1. On the left sidebar, select **Settings > General**.
1. Expand the **Visibility and access controls** section.
......@@ -200,7 +200,7 @@ For more details on project visibility, see
You can specify from which hosting sites users can [import their projects](../../project/import/index.md):
1. Sign in to GitLab as a user with [Administrator role](../../permissions.md).
1. Sign in to GitLab as a user with Administrator access level.
1. On the top bar, select **Menu > Admin**.
1. On the left sidebar, select **Settings > General**.
1. Expand the **Visibility and access controls** section.
......@@ -212,7 +212,7 @@ You can specify from which hosting sites users can [import their projects](../..
To enable the export of
[projects and their data](../../../user/project/settings/import_export.md#export-a-project-and-its-data):
1. Sign in to GitLab as a user with [Administrator role](../../permissions.md).
1. Sign in to GitLab as a user with Administrator access level.
1. On the top bar, select **Menu > Admin**.
1. On the left sidebar, select **Settings > General**.
1. Expand the **Visibility and access controls** section.
......@@ -228,7 +228,7 @@ The GitLab restrictions apply at the application level.
To specify the enabled Git access protocols:
1. Sign in to GitLab as a user with [Administrator role](../../permissions.md).
1. Sign in to GitLab as a user with Administrator access level.
1. On the top bar, select **Menu > Admin**.
1. On the left sidebar, select **Settings > General**.
1. Expand the **Visibility and access controls** section.
......
......@@ -17,7 +17,7 @@ requests, and:
- Take action on individual merge requests.
- Reduce overall cycle time.
Code Review Analytics is available to users with at least the Reporter [role](../permissions.md), and displays a table of open merge requests that have at least one non-author comment. The review time is measured from the time the first non-author comment was submitted.
Code Review Analytics is available to users with at least the Reporter role, and displays a table of open merge requests that have at least one non-author comment. The review time is measured from the time the first non-author comment was submitted.
NOTE:
Initially, no data appears. Data is populated as users comment on open merge requests.
......
......@@ -116,4 +116,4 @@ bookmark for those preferred settings in your browser.
The **Merge Request Analytics** feature can be accessed only:
- On [GitLab Premium](https://about.gitlab.com/pricing/) and above.
- By users with at least the Reporter [role](../permissions.md).
- By users with at least the Reporter role.
......@@ -65,7 +65,7 @@ request is merged. Select the dropdown to view:
The right-side histogram shows the size or complexity of a merge request.
Select the dropdown to view:
- Number of commits per merge request.
- Number of lines of code (LOC) per commit.
- Number of files touched.
......@@ -103,4 +103,4 @@ You can filter analytics based on a date range. To filter results:
The **Productivity Analytics** dashboard can be accessed only:
- On [GitLab Premium](https://about.gitlab.com/pricing/) and above.
- By users with at least the Reporter [role](../permissions.md).
- By users with at least the Reporter role.
......@@ -218,7 +218,7 @@ An approval is optional when the security report:
the rule's severity levels.
- Contains a vulnerability count equal to or less than what the rule allows.
Project members assigned [at least the Maintainer role](../permissions.md#project-members-permissions) can enable or edit
Project members with at least the Maintainer role can enable or edit
the Vulnerability-Check rule.
#### Enable the Vulnerability-Check rule
......
......@@ -157,7 +157,7 @@ information to the cluster automatically without downtime.
## View your Agents
If you have the [Developer role](../../../permissions.md) or above, you can access the Agent's
If you have at least the Developer role, you can access the Agent's
configuration repository and view the Agent's list:
1. On the left sidebar, select **Infrastructure > Kubernetes clusters**.
......
......@@ -22,7 +22,7 @@ insights within GitLab:
## Configure cluster cost management
To get started with cluster cost management, you need the [Maintainer role](../permissions.md) in a project or group.
To get started with cluster cost management, you need the Maintainer role for a project or group.
1. Clone the [`kubecost-cost-model`](https://gitlab.com/gitlab-examples/kubecost-cost-model/)
example repository, which contains minor modifications to the upstream Kubecost
......
......@@ -772,7 +772,7 @@ Developers of the project can view the policies configured in a project.
Prerequisites:
- Maintainer or Owner [role](../../permissions.md#project-members-permissions).
- Maintainer or Owner role.
`License-Check` is a [merge request approval](../../project/merge_requests/approvals/index.md) rule
you can enable to allow an individual or group to approve a merge request that contains a `denied`
......
......@@ -115,8 +115,7 @@ You can use [Markdown](../markdown.md) and [quick actions](../project/quick_acti
You can edit your own comment at any time.
Anyone with the [Maintainer role](../permissions.md) or
higher can also edit a comment made by someone else.
Anyone with at least the Maintainer role can also edit a comment made by someone else.
## Prevent comments by locking an issue
......@@ -209,7 +208,7 @@ When you reply to a standard comment, you create a thread.
Prerequisites:
- You must have at least the [Guest role](../permissions.md#project-members-permissions).
- You must have at least the Guest role.
- You must be in an issue, merge request, or epic. Threads in commits and snippets are not supported.
To create a thread by replying to a comment:
......@@ -231,7 +230,7 @@ You can create a thread without replying to a standard comment.
Prerequisites:
- You must have at least the [Guest role](../permissions.md#project-members-permissions).
- You must have at least the Guest role.
- You must be in an issue, merge request, commit, or snippet.
To create a thread:
......@@ -253,7 +252,7 @@ In a merge request, you can resolve a thread when you want to finish a conversat
Prerequisites:
- You must have at least the [Developer role](../permissions.md#project-members-permissions)
- You must have at least the Developer role
or be the author of the change being reviewed.
- Resolvable threads can be added only to merge requests. It doesn't work
for comments in issues, commits, or snippets.
......
......@@ -24,7 +24,7 @@ You can also configure [custom templates for the instance](../admin_area/custom_
Prerequisite:
- You must have the [Owner role for the group](../permissions.md#group-members-permissions).
- You must have the Owner role for the group.
To set up custom project templates in a group, add the subgroup that contains the
project templates to the group settings:
......
......@@ -32,7 +32,7 @@ how to use those features.
Prerequisite:
- You must have at least the [Reporter role](../../permissions.md) for the group.
- You must have at least the Reporter role for the group.
To view DevOps Adoption:
......
......@@ -24,7 +24,7 @@ To view an epic board:
Prerequisites:
- You must have at least the [Reporter role](../../permissions.md#group-members-permissions) for a group.
- You must have at least the Reporter role for a group.
To create a new epic board:
......@@ -49,7 +49,7 @@ To change these options later, [edit the board](#edit-the-scope-of-an-epic-board
Prerequisites:
- You must have at least the [Reporter role](../../permissions.md#group-members-permissions) for a group.
- You must have at least the Reporter role for a group.
- A minimum of two boards present in a group.
To delete the active epic board:
......@@ -73,7 +73,7 @@ To delete the active epic board:
Prerequisites:
- You must have at least the [Reporter role](../../permissions.md#group-members-permissions) for a group.
- You must have at least the Reporter role for a group.
To create a new list:
......@@ -91,7 +91,7 @@ list view that's removed. You can always create it again later if you need.
Prerequisites:
- You must have at least the [Reporter role](../../permissions.md#group-members-permissions) for a group.
- You must have at least the Reporter role for a group.
To remove a list from an epic board:
......@@ -106,7 +106,7 @@ To remove a list from an epic board:
Prerequisites:
- You must have at least the [Reporter role](../../permissions.md#group-members-permissions) for a group.
- You must have at least the Reporter role for a group.
- You must have [created a list](#create-a-new-list) first.
To create an epic from a list in epic board:
......@@ -147,7 +147,7 @@ You can move epics and lists by dragging them.
Prerequisites:
- You must have at least the [Reporter role](../../permissions.md#group-members-permissions) for a group.
- You must have at least the Reporter role for a group.
To move an epic, select the epic card and drag it to another position in its current list or
into another list. Learn about possible effects in [Dragging epics between lists](#dragging-epics-between-lists).
......@@ -170,7 +170,7 @@ and the target list.
Prerequisites:
- You must have at least the [Reporter role](../../permissions.md#group-members-permissions) for a group.
- You must have at least the Reporter role for a group.
To edit the scope of an epic board:
......
......@@ -83,7 +83,7 @@ To edit an epic's start date, due date, or labels:
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/7250) in GitLab 12.2.
Users with at least the [Reporter role](../../permissions.md) can manage epics.
Users with at least the Reporter role can manage epics.
When bulk editing epics in a group, you can edit their labels.
......@@ -98,8 +98,7 @@ To update multiple epics at the same time:
## Delete an epic
NOTE:
To delete an epic, you must be an [Owner](../../permissions.md#group-members-permissions) of a group
or subgroup.
To delete an epic, you must be an Owner of a group or subgroup.
To delete the epic:
......
......@@ -138,7 +138,7 @@ your group.
## Change the owner of a group
You can change the owner of a group. Each group must always have at least one
member with the [Owner role](../permissions.md#group-members-permissions).
member with the Owner role.
- As an administrator:
1. Go to the group and from the left menu, select **Group information > Members**.
......@@ -153,7 +153,7 @@ member with the [Owner role](../permissions.md#group-members-permissions).
Prerequisites:
- You must have the [Owner role](../permissions.md#group-members-permissions).
- You must have the Owner role.
- The member must have direct membership in the group. If
membership is inherited from a parent group, then the member can be removed
from the parent group only.
......@@ -250,7 +250,7 @@ There are two different ways to add a new project to a group:
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/2534) in GitLab 10.5.
> - [Moved](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/25975) from GitLab Premium to GitLab Free in 11.10.
By default, [Developers and Maintainers](../permissions.md#group-members-permissions) can create projects under a group.
By default, users with at least the Developer role can create projects under a group.
To change this setting for a specific group:
......@@ -534,7 +534,7 @@ disabled for the group and its subgroups.
Prerequisite:
- You must be assigned the [Owner role](../permissions.md#group-members-permissions) for the group.
- You must be assigned the Owner role) for the group.
To specify a user cap:
......@@ -556,7 +556,7 @@ You can remove the user cap, so there is no limit on the number of members you c
Prerequisite:
- You must be assigned the [Owner role](../permissions.md#group-members-permissions) for the group.
- You must be assigned the Owner role) for the group.
To remove the user cap:
......@@ -575,7 +575,7 @@ and must be approved.
Prerequisite:
- You must be assigned the [Owner role](../permissions.md#group-members-permissions) for the group.
- You must be assigned the Owner role) for the group.
To approve members that are pending because they've exceeded the user cap:
......
......@@ -52,7 +52,7 @@ With iteration cadences enabled, you must first
Prerequisites:
- You must have at least the [Developer role](../../permissions.md) for a group.
- You must have at least the Developer role for a group.
To create an iteration cadence:
......@@ -65,7 +65,7 @@ To create an iteration cadence:
Prerequisites:
- You must have at least the [Developer role](../../permissions.md) for a group.
- You must have at least the Developer role for a group.
Deleting an iteration cadence also deletes all iterations within that cadence.
......@@ -86,7 +86,7 @@ From there you can create a new iteration or select an iteration to get a more d
Prerequisites:
- You must have at least the [Developer role](../../permissions.md) for a group.
- You must have at least the Developer role for a group.
For manually scheduled iteration cadences, you create and add iterations yourself.
......@@ -104,7 +104,7 @@ To create an iteration:
Prerequisites:
- You must have at least the [Developer role](../../permissions.md) for a group.
- You must have at least the Developer role for a group.
To edit an iteration, select the three-dot menu (**{ellipsis_v}**) > **Edit**.
......@@ -114,7 +114,7 @@ To edit an iteration, select the three-dot menu (**{ellipsis_v}**) > **Edit**.
Prerequisites:
- You must have at least the [Developer role](../../permissions.md) for a group.
- You must have at least the Developer role for a group.
To delete an iteration, select the three-dot menu (**{ellipsis_v}**) > **Delete**.
......
......@@ -16,7 +16,7 @@ You can also [export projects](../../project/settings/import_export.md).
Prerequisite:
- You must have the [Owner role](../../permissions.md) for the group.
- You must have the Owner role for the group.
To enable import and export for a group:
......@@ -69,7 +69,7 @@ in GitLab 14.6 and replaced by [GitLab Migration](../import/).
Prerequisites:
- You must have the [Owner role](../../permissions.md) for the group.
- You must have the Owner role for the group.
To export the contents of a group:
......
......@@ -158,7 +158,7 @@ added to), add the user to the new subgroup again with a higher set of permissio
For example, if User 1 was first added to group `one/two` with Developer
permissions, then they inherit those permissions in every other subgroup
of `one/two`. To give them the [Maintainer role](../../permissions.md) for group `one/two/three/four`,
of `one/two`. To give them the Maintainer role for group `one/two/three/four`,
you would add them again in that group as Maintainer. Removing them from that group,
the permissions fall back to those of the ancestor group.
......
......@@ -16,7 +16,7 @@ enabling you to see statistics about the resources that Terraform creates,
modifies, or destroys.
WARNING:
Like any other job artifact, Terraform Plan data is viewable by anyone with the Guest [role](../../permissions.md) on the repository.
Like any other job artifact, Terraform Plan data is viewable by anyone with the Guest role for the repository.
Neither Terraform nor GitLab encrypts the plan file by default. If your Terraform Plan
includes sensitive data such as passwords, access tokens, or certificates, we strongly
recommend encrypting plan output or modifying the project visibility settings.
......
......@@ -33,11 +33,13 @@ before using this feature.
## Permissions for using Terraform
In GitLab version 13.1, the [Maintainer role](../../permissions.md) was required to use a
GitLab managed Terraform state backend. In GitLab versions 13.2 and greater, the
[Maintainer role](../../permissions.md) is required to lock, unlock, and write to the state
(using `terraform apply`), while the [Developer role](../../permissions.md) is required to read
the state (using `terraform plan -lock=false`).
In GitLab version 13.1, the Maintainer role was required to use a
GitLab managed Terraform state backend.
In GitLab versions 13.2 and later:
- The Maintainer role is required to lock, unlock, and write to the state (using `terraform apply`).
- The Developer role is required to read the state (using `terraform plan -lock=false`).
## Set up GitLab-managed Terraform state
......@@ -205,7 +207,7 @@ and the CI YAML file:
The output from the above `terraform` commands should be viewable in the job logs.
WARNING:
Like any other job artifact, Terraform plan data is viewable by anyone with the Guest [role](../../permissions.md) on the repository.
Like any other job artifact, Terraform plan data is viewable by anyone with the Guest role on the repository.
Neither Terraform nor GitLab encrypts the plan file by default. If your Terraform plan
includes sensitive data such as passwords, access tokens, or certificates, GitLab strongly
recommends encrypting plan output or modifying the project visibility settings.
......@@ -255,7 +257,7 @@ An example setup is shown below:
Outputs from the data source can now be referenced in your Terraform resources
using `data.terraform_remote_state.example.outputs.<OUTPUT-NAME>`.
You need at least the [Developer role](../../permissions.md) in the target project
You need at least the Developer role in the target project
to read the Terraform state.
## Migrating to GitLab Managed Terraform state
......@@ -365,7 +367,7 @@ location. You can then go back to running it in GitLab CI/CD.
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/273592) in GitLab 13.8.
Users with Developer and greater [permissions](../../permissions.md) can view the
Users with at least the Developer role can view the
state files attached to a project at **Infrastructure > Terraform**. Users with the
Maintainer role can perform commands on the state files. The user interface
contains these fields:
......@@ -404,7 +406,7 @@ curl --header "Private-Token: <your_access_token>" --request DELETE "https://git
## Remove a state file
Users with Maintainer and greater [permissions](../../permissions.md) can use the
Users with at least the Maintainer role can use the
following options to remove a state file:
- **GitLab UI**: Go to **Infrastructure > Terraform**. In the **Actions** column,
......
......@@ -93,9 +93,8 @@ You can authenticate using:
- A [personal access token](../../../user/profile/personal_access_tokens.md) with the scope set to `read_registry` and `write_registry`.
- A [group deploy token](../../../user/project/deploy_tokens/index.md#group-deploy-token) with the scope set to `read_registry` and `write_registry`.
Users accessing the Dependency Proxy with a personal access token or username and password require
at least [Guest membership](../../permissions.md#group-members-permissions)
to the group they pull images from.
Users accessing the Dependency Proxy with a personal access token or username and password must
have at least the Guest role for the group they pull images from.
#### SAML SSO
......
......@@ -29,7 +29,7 @@ repository in automation, it's a simple solution.
A drawback is that your repository could become vulnerable if a remote machine is compromised
by a hacker. You should limit access to the remote machine before a deploy key is
enabled on your repository. A good rule to follow is to provide access only to trusted users,
and make sure that the allowed users have at least the [Maintainer role](../../permissions.md)
and make sure that the allowed users have at least the Maintainer role
in the GitLab project.
If this security implication is a concern for your organization,
......
......@@ -14,7 +14,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
Deploy tokens allow you to download (`git clone`) or push and pull packages and
container registry images of a project without having a user and a password.
Deploy tokens can be managed by [maintainers only](../../permissions.md).
Deploy tokens can be managed only by users with the Maintainer role.
Deploy tokens cannot be used with the GitLab API.
......
......@@ -33,7 +33,7 @@ GitLab supports two different modes of file locking:
## Permissions
Locks can be created by any person who has at least
[Developer role](../permissions.md) in the repository.
Developer role in the repository.
Only the user who locked the file or directory can edit locked files. Other
users are prevented from modifying locked files by pushing, merging,
......@@ -77,7 +77,7 @@ Check this document to learn more about [using Git LFS](../../topics/git/lfs/ind
### Configure Exclusive File Locks
You need the [Maintainer role](../permissions.md) to configure
You need the Maintainer role
Exclusive File Locks for your project through the command line.
The first thing to do before using File Locking is to tell Git LFS which
......@@ -226,4 +226,4 @@ To view and remove file locks:
This list shows all the files locked either through LFS or GitLab UI.
Locks can be removed by their author, or any user
with at least the [Maintainer role](../permissions.md).
with at least the Maintainer role.
......@@ -40,9 +40,8 @@ iterations of the GitLab Jira importer.
### Permissions
In order to be able to import issues from a Jira project you need to have read access on Jira
issues and a [Maintainer or higher](../../permissions.md#project-members-permissions) role in the
GitLab project that you wish to import into.
To be able to import issues from a Jira project you must have read access on Jira
issues and at least the Maintainer role in the GitLab project that you wish to import into.
### Jira integration
......
......@@ -8,7 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
You can find the available integrations under your project's
**Settings > Integrations** page. You need to have at least
the [Maintainer role](../../permissions.md) on the project.
the Maintainer role on the project.
## Integrations
......
......@@ -67,7 +67,7 @@ After you enable custom slash commands in Mattermost, you need configuration
information from GitLab. To get this information:
1. In a different browser tab than your current Mattermost session, sign in to
GitLab as a user with [Administrator role](../../permissions.md).
GitLab as a user with the administrator access level.
1. On the top bar, select **Menu > Admin**.
1. In the left menu, select **Settings > Integrations**, then select
**Mattermost slash commands**.
......
......@@ -194,7 +194,7 @@ card includes:
## Permissions
Users with the [Reporter and higher roles](../permissions.md) can use all the functionality of the
Users with at least the Reporter role can use all the functionality of the
issue board feature to create or delete lists. They can also drag issues from one list to another.
## Ordering issues in a list
......@@ -569,7 +569,7 @@ You can move issues and lists by dragging them.
Prerequisites:
- You must have at least the Reporter [role](../permissions.md#project-members-permissions) for a project in GitLab.
- You must have at least the Reporter role for a project in GitLab.
To move an issue, select the issue card and drag it to another position in its current list or
into a different list. Learn about possible effects in [Dragging issues between lists](#dragging-issues-between-lists).
......
......@@ -25,7 +25,7 @@ In an issue, leave a comment using the `/zoom` quick action followed by a valid
/zoom https://zoom.us/j/123456789
```
If the Zoom meeting URL is valid and you have at least the Reporter [role](../../permissions.md),
If the Zoom meeting URL is valid and you have at least the Reporter role,
a system alert notifies you of its successful addition.
The issue's description is automatically edited to include the Zoom link, and a button
appears right under the issue's title.
......@@ -44,5 +44,5 @@ Similarly to adding a Zoom meeting, you can remove it with a quick action:
/remove_zoom
```
If you have at least the Reporter [role](../../permissions.md),
If you have at least the Reporter role,
a system alert notifies you that the meeting URL was successfully removed.
......@@ -42,7 +42,7 @@ system note in the issue's comments.
![Confidential issues system notes](img/confidential_issues_system_notes.png)
When an issue is made confidential, only users with at least the [Reporter role](../../permissions.md)
When an issue is made confidential, only users with at least the Reporter role
for the project have access to the issue.
Users with Guest or [Minimal](../../permissions.md#users-with-minimal-access) roles can't access
the issue even if they were actively participating before the change.
......@@ -82,11 +82,11 @@ that prevent leaks of private data.
There are two kinds of level access for confidential issues. The general rule
is that confidential issues are visible only to members of a project with at
least the Reporter [role](../../permissions.md#project-members-permissions). However, a guest user can also create
least the Reporter role. 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 the [Maintainer role](../../permissions.md) and the Guest role
For example, here's what a user with the Maintainer role and the Guest role
sees in the project's search results respectively.
| Maintainer role | Guest role |
......
......@@ -14,9 +14,7 @@ retain columns such as labels and milestones, consider the [Move Issue feature](
The user uploading the CSV file is set as the author of the imported issues.
NOTE:
A permission level of [Developer](../../permissions.md), or higher, is required
to import issues.
You must have at least the Developer role for a project to import issues.
## Prepare for the import
......
......@@ -7,7 +7,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# Due dates **(FREE)**
Due dates can be used in [issues](index.md) to keep track of deadlines and make sure features are
shipped on time. Users need at least the Reporter [role](../../permissions.md)
shipped on time. Users need at least the Reporter role
to be able to edit the due date. All users with permission to view
the issue can view the due date.
......
......@@ -29,7 +29,7 @@ You can create an issue in many ways in GitLab:
Prerequisites:
- You must have at least the [Guest role](../../permissions.md) for the project.
- You must have at least the Guest role for the project.
To create an issue:
......@@ -52,7 +52,7 @@ to the projects in the group.
Prerequisites:
- You must have at least the [Guest role](../../permissions.md) for the project in the group.
- You must have at least the Guest role for the project in the group.
To create an issue from a group:
......@@ -78,7 +78,7 @@ You can create a new issue from an existing one. The two issues can then be mark
Prerequisites:
- You must have at least the [Guest role](../../permissions.md) for the project.
- You must have at least the Guest role for the project.
To create an issue from another issue:
......@@ -98,7 +98,7 @@ You can create a new issue from an [issue board](../issue_board.md).
Prerequisites:
- You must have at least the [Guest role](../../permissions.md) for the project.
- You must have at least the Guest role for the project.
To create an issue from a project issue board:
......@@ -133,7 +133,7 @@ Prerequisites:
- Your GitLab instance must have [incoming email](../../../administration/incoming_email.md)
configured.
- There must be at least one issue in the issue list.
- You must have at least the [Guest role](../../permissions.md) for the project.
- You must have at least the Guest role for the project.
To email an issue to a project:
......@@ -224,7 +224,7 @@ You can edit an issue's title and description.
Prerequisites:
- You must have at least the [Reporter role](../../permissions.md) for the project, be the author of the issue, or be assigned to the issue.
- You must have at least the Reporter role for the project, be the author of the issue, or be assigned to the issue.
To edit an issue:
......@@ -242,7 +242,7 @@ You can edit multiple issues at a time when you're in a project.
Prerequisites:
- You must have at least the [Reporter role](../../permissions.md) for the project.
- You must have at least the Reporter role for the project.
To edit multiple issues at the same time:
......@@ -275,7 +275,7 @@ You can edit multiple issues across multiple projects when you're in a group.
Prerequisites:
- You must have at least the [Reporter role](../../permissions.md) for a group.
- You must have at least the Reporter role for a group.
To edit multiple issues at the same time:
......@@ -304,7 +304,7 @@ Be careful when moving an issue to a project with different access rules. Before
Prerequisites:
- You must have at least the [Reporter role](../../permissions.md) for the project.
- You must have at least the Reporter role for the project.
To move an issue:
......@@ -319,7 +319,7 @@ You can move all open issues from one project to another.
Prerequisites:
- You must have at least the [Reporter role](../../permissions.md) for the project.
- You must have at least the Reporter role for the project.
To do it:
......@@ -353,7 +353,7 @@ The issue is marked as closed but is not deleted.
Prerequisites:
- You must have at least the [Reporter role](../../permissions.md) for the project, be the author of the issue, or be assigned to the issue.
- You must have at least the Reporter role for the project, be the author of the issue, or be assigned to the issue.
To close an issue, you can do the following:
......@@ -366,7 +366,7 @@ To close an issue, you can do the following:
Prerequisites:
- You must have at least the [Reporter role](../../permissions.md) for the project, be the author of the issue, or be assigned to the issue.
- You must have at least the Reporter role for the project, be the author of the issue, or be assigned to the issue.
To reopen a closed issue, at the top of the issue, select **Reopen issue**.
A reopened issue is no different from any other open issue.
......@@ -442,7 +442,7 @@ in the [project's settings](../settings/index.md).
Prerequisites:
- You must have at least the [Maintainer role](../../permissions.md) for the project.
- You must have at least the Maintainer role for the project.
To disable automatic issue closing:
......@@ -478,7 +478,7 @@ of your installation.
Prerequisites:
- You must be the issue author or have at least the [Reporter role](../../permissions.md) for the project, be the author of the issue, or be assigned to the issue.
- You must be the issue author or have at least the Reporter role for the project, be the author of the issue, or be assigned to the issue.
To change issue type:
......@@ -496,7 +496,7 @@ To change issue type:
Prerequisites:
- You must have the [Owner role](../../permissions.md) for a project.
- You must have the Owner role for a project.
To delete an issue:
......@@ -624,7 +624,7 @@ This status marks issues as progressing as planned or needing attention to keep
Prerequisites:
- You must have at least the [Reporter role](../../permissions.md) for the project.
- You must have at least the Reporter role for the project.
To edit health status of an issue:
......
......@@ -25,7 +25,7 @@ To manage linked issues through our API, visit the [issue links API documentatio
Prerequisites:
- You must have at least the Reporter [role](../../permissions.md) for both projects.
- You must have at least the Reporter role for both projects.
To link one issue to another:
......
......@@ -17,7 +17,7 @@ to perform actions.
Prerequisite:
- You must have the [Maintainer or Owner role](../../permissions.md).
- You must have the Maintainer or Owner role.
To add a user to a project:
......@@ -48,7 +48,7 @@ Each user's access is based on:
Prerequisite:
- You must have the [Maintainer or Owner role](../../permissions.md).
- You must have the Maintainer or Owner role.
To add groups to a project:
......@@ -72,7 +72,7 @@ retain the same permissions as the project you import them from.
Prerequisite:
- You must have the [Maintainer or Owner role](../../permissions.md).
- You must have the Maintainer or Owner role.
To import users:
......@@ -111,7 +111,7 @@ group itself.
Prerequisites:
- You must have the [Owner role](../../permissions.md).
- You must have the Owner role.
- Optional. Unassign the member from all issues and merge requests that
are assigned to them.
......
......@@ -50,7 +50,7 @@ You can push directly to the branch of the forked repository if:
- The author of the merge request has enabled contributions from upstream
members.
- You have at least the [Developer role](../../permissions.md) in the
- You have at least the Developer role in the
upstream project.
In the following example:
......
......@@ -165,7 +165,7 @@ for protected branches.
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/40491) in GitLab 13.4.
> - Moved to GitLab Premium in 13.9.
You may have to grant users with the Reporter [role](../../../permissions.md#project-members-permissions)
You may have to grant users with the Reporter role
permission to approve merge requests before they can merge to a protected branch.
Some users (like managers) may not need permission to push or merge code, but still need
oversight on proposed work. To enable approval permissions for these users without
......
......@@ -16,7 +16,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 the [Maintainer role](../../permissions.md) and the regular developers
The project maintainers get the Maintainer role and the regular developers
get the Developer role.
Maintainers mark the authoritative branches as 'Protected'.
......@@ -25,7 +25,7 @@ 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 the [Maintainer role](../../permissions.md) can merge changes into a
By default, only users with the Maintainer role can merge changes into a
protected branch.
**Advantages**
......@@ -39,7 +39,7 @@ protected branch.
## Forking workflow
With the forking workflow, maintainers get the [Maintainer role](../../permissions.md) and regular
With the forking workflow, maintainers get the Maintainer role and regular
developers get the Reporter role on the authoritative repository, which prohibits
them from pushing any changes to it.
......
......@@ -44,7 +44,7 @@ as a draft. This feature is scheduled for removal in GitLab 14.0. Use `Draft:` i
When a merge request is ready to be merged, you can remove the `Draft` flag in several ways:
- **Viewing a merge request**: In the top right corner of the merge request, click **Mark as ready**.
Users with [Developer or greater permissions](../../permissions.md)
Users with at least the Developer role
can also scroll to the bottom of the merge request description and click **Mark as ready**:
![Mark as ready](img/draft_blocked_merge_button_v13_10.png)
......
......@@ -162,7 +162,7 @@ enabled by default for all new merge requests, enable it in the
This option is also visible in an existing merge request next to
the merge request button and can be selected or deselected before merging.
It is only visible to users with the [Maintainer role](../../permissions.md)
It is only visible to users with the Maintainer role
in the source project.
If the user viewing the merge request does not have the correct
......
......@@ -94,7 +94,7 @@ You cannot undo the deletion of a merge request.
To delete a merge request:
1. Sign in to GitLab as a user with the project Owner [role](../../permissions.md).
1. Sign in to GitLab as a user with the project Owner role.
Only users with this role can delete merge requests in a project.
1. Go to the merge request you want to delete, and select **Edit**.
1. Scroll to the bottom of the page, and select **Delete merge request**.
......
......@@ -160,7 +160,7 @@ Multiline comments display the comment's line numbers above the body of the comm
## Bulk edit merge requests at the project level
Users with permission level of [Developer or higher](../../../permissions.md) can manage merge requests.
Users with at least the Developer role can manage merge requests.
When bulk-editing merge requests in a project, you can edit the following attributes:
......@@ -183,7 +183,7 @@ To update multiple project merge requests at the same time:
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/12719) in GitLab 12.2.
Users with permission level of [Developer or higher](../../../permissions.md) can manage merge requests.
Users with at least the Developer role can manage merge requests.
When bulk editing merge requests in a group, you can edit the following attributes:
......
......@@ -42,7 +42,7 @@ After the author applies a suggestion:
1. The suggestion is marked as **Applied**.
1. The thread is resolved.
1. GitLab creates a new commit with the changes.
1. If the user has the [Developer role](../../../permissions.md), GitLab pushes
1. If the user has the Developer role, GitLab pushes
the suggested change directly into the codebase in the merge request's branch.
## Multi-line suggestions
......
......@@ -53,8 +53,7 @@ If you're in a project and select **Issues > Milestones**, GitLab displays only
## Creating milestones
NOTE:
A permission level of [Developer or higher](../../permissions.md) is required to create milestones.
Users with at least the Developer role can create milestones.
Milestones can be created either at project or group level.
......@@ -70,8 +69,7 @@ To create a milestone:
## Editing milestones
NOTE:
A permission level of [Developer or higher](../../permissions.md) is required to edit milestones.
Users with at least the Developer role can edit milestones.
To edit a milestone:
......
......@@ -35,7 +35,7 @@ Administrators can set a default branch protection level in the
Prerequisite:
- You must have at least the [Maintainer role](../permissions.md).
- You must have at least the Maintainer role.
To protect a branch:
......@@ -52,7 +52,7 @@ The protected branch displays in the list of protected branches.
Prerequisite:
- You must have at least the [Maintainer role](../permissions.md).
- You must have at least the Maintainer role.
To protect multiple branches at the same time:
......@@ -75,7 +75,7 @@ The protected branch displays in the list of protected branches.
## Create a protected branch
Users with the Developer or higher [role](../permissions.md) can create a protected branch.
Users with at least the Developer role can create a protected branch.
Prerequisites:
......@@ -217,7 +217,7 @@ for details about the pipelines security model.
## Delete a protected branch
Users with the [Maintainer role](../permissions.md) and greater can manually delete protected
Users with at least the Maintainer can manually delete protected
branches by using the GitLab web interface:
1. Go to **Repository > Branches**.
......
......@@ -22,12 +22,12 @@ This feature evolved out of [protected branches](protected_branches.md)
By default:
- To create tags, you must have the [Maintainer role](../permissions.md).
- To create tags, you must have the Maintainer role.
- No one can update or delete tags.
## Configuring protected tags
To protect a tag, you need to have at least the [Maintainer role](../permissions.md).
To protect a tag, you need to have at least the Maintainer role.
1. Go to the project's **Settings > Repository**.
......
......@@ -393,7 +393,7 @@ deploy_to_production:
To set a deploy freeze window in the UI, complete these steps:
1. Sign in to GitLab as a user with the [Maintainer role](../../permissions.md).
1. Sign in to GitLab as a user with the Maintainer role.
1. On the left sidebar, select **Project information**.
1. In the left navigation menu, navigate to **Settings > CI/CD**.
1. Scroll to **Deploy freezes**.
......@@ -767,22 +767,22 @@ In the API:
> [Changes were made to the Guest role access](https://gitlab.com/gitlab-org/gitlab/-/issues/335209) in GitLab 14.5.
- Users with the [Reporter role or above](../../../user/permissions.md#project-members-permissions)
- Users with at least the Reporter role
have read and download access to the project releases.
- Users with the [Guest role](../../../user/permissions.md#project-members-permissions)
- Users with the Guest role
have read and download access to the project releases.
This includes associated Git-tag-names, release description, author information of the releases.
However, other repository-related information, such as [source code](#source-code), [release evidence](#release-evidence) are redacted.
### Create, update, and delete a release and its assets
- Users with [Developer role or above](../../../user/permissions.md#project-members-permissions)
- Users with at least the Developer role
have write access to the project releases and assets.
- If a release is associated with a [protected tag](../protected_tags.md),
the user must be [allowed to create the protected tag](../protected_tags.md#configuring-protected-tags) too.
As an example of release permission control, you can allow only
[Maintainer role or above](../../../user/permissions.md#project-members-permissions)
users with at least the Maintainer role
to create, update, and delete releases by protecting the tag with a wildcard (`*`),
and set **Maintainer** in the **Allowed to create** column.
......
......@@ -38,7 +38,7 @@ the [Git commands you need](#update-the-default-branch-name-in-your-repository)
To update the default branch name for an individual [project](../../index.md):
1. Sign in to GitLab with at least the [Maintainer](../../../permissions.md) role.
1. Sign in to GitLab with at least the Maintainer role.
1. In the left navigation menu, go to **Settings > Repository**.
1. Expand **Default branch**, and select a new default branch.
1. Optional. Select the **Auto-close referenced issues on default branch** checkbox to close
......@@ -129,7 +129,7 @@ renames a Git repository's (`example`) default branch.
git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/main
```
1. Sign in to GitLab with at least the [Maintainer](../../../permissions.md)
1. Sign in to GitLab with at least the Maintainer
role and follow the instructions to
[change the default branch for this project](#change-the-default-branch-name-for-a-project).
Select `main` as your new default branch.
......
......@@ -27,16 +27,15 @@ To fork an existing project in GitLab:
1. Select the project to fork to:
- Recommended method. Below **Select a namespace to fork the project**, identify
the project you want to fork to, and click **Select**. Only namespaces you have
Developer and higher [permissions](../../permissions.md) for are shown.
the project you want to fork to, and click **Select**. Only namespaces where you have
at least the Developer role for are shown.
![Choose namespace](img/forking_workflow_choose_namespace_v13_10.png)
- Experimental method. If your GitLab administrator has
[enabled the experimental fork project form](#enable-or-disable-the-fork-project-form), read
[Create a fork with the fork project form](#create-a-fork-with-the-fork-project-form).
Only namespaces you have at least the Developer
[role](../../permissions.md) for are shown.
Only namespaces where you have at least the Developer role for are shown.
NOTE:
The project path must be unique in the namespace.
......
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
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