Merge branch 'eread/add-reporter-and-guest-to-vale' into 'master'

Add new substitution rules relating to roles

See merge request gitlab-org/gitlab!74569

doc/.vale/gitlab/Substitutions.yml

@@ -41,9 +41,15 @@ swap:
   developer access: the Developer role
   developer permission: the Developer role
   developer permissions: the Developer role
+  guest access: the Guest role
+  guest permission: the Guest role
+  guest permissions: the Guest role
   maintainer access: the Maintainer role
   maintainer permission: the Maintainer role
   maintainer permissions: the Maintainer role
   owner access: the Owner role
   owner permission: the Owner role
   owner permissions: the Owner role
+  reporter access: the Reporter role
+  reporter permission: the Reporter role
+  reporter permissions: the Reporter role

doc/api/dora/metrics.md

@@ -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 [reporter permissions and above](../../user/permissions.md).
+All methods require at least the Reporter [role](../../user/permissions.md).
 
 ## Get project-level DORA metrics
 

doc/ci/environments/index.md

@@ -27,7 +27,7 @@ You can even access a [web terminal](#web-terminals-deprecated) for your environ
 
 Prerequisites:
 
-- You must have a minimum of [Reporter permission](../../user/permissions.md#project-members-permissions).
+- You must have at least the Reporter [role](../../user/permissions.md#project-members-permissions).
 
 To view a list of environments and deployments:
 

doc/ci/environments/protected_environments.md

@@ -102,10 +102,9 @@ 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
-[Reporter permissions](../../user/permissions.md), can only be granted access to
-protected environments with this method.
+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
+method.
 
 ## Deployment branch access
 
@@ -126,8 +125,8 @@ 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 permission, or in groups added to the project with Reporter permissions,
-appears in the dropdown menu for deployment-only access.
+group with the Reporter [role](../../user/permissions.md), 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 +135,8 @@ To add deployment-only access:
 1. Invite the group to be a project member.
 1. Follow the steps in [Protecting Environments](#protecting-environments).
 
-Note that deployment-only access is the only possible access level for groups with [Reporter permissions](../../user/permissions.md).
+Note that deployment-only access is the only possible access level for groups with the Reporter
+[role](../../user/permissions.md).
 
 ## Modifying and unprotecting environments
 

doc/development/policies.md

@@ -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 Reporter access to
+the rule was activated because the user `john` had the Reporter [role](../user/permissions.md) on
 `Project/4`.
 
 When a policy is asked whether a particular ability is allowed

doc/user/analytics/code_review_analytics.md

@@ -22,7 +22,7 @@ Initially, no data appears. Data is populated as users comment on open merge req
 
 ## Overview
 
-Code Review Analytics is available to users with Reporter access and above, 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](../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.
 
 To access Code Review Analytics, from your project's menu, go to **Analytics > Code Review**.
 

doc/user/analytics/merge_request_analytics.md

@@ -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 [Reporter access](../permissions.md) and above.
+- By users with at least the Reporter [role](../permissions.md).

doc/user/analytics/productivity_analytics.md

@@ -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 [Reporter access](../permissions.md) and above.
+- By users with at least the Reporter [role](../permissions.md).

doc/user/infrastructure/iac/mr_integration.md

@@ -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 Guest access](../../permissions.md) to the repository.
+Like any other job artifact, Terraform Plan data is viewable by anyone with the Guest [role](../../permissions.md) 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, we strongly
 recommend encrypting plan output or modifying the project visibility settings.

doc/user/infrastructure/iac/terraform_state.md

@@ -205,7 +205,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 Guest access](../../permissions.md) to the repository.
+Like any other job artifact, Terraform plan data is viewable by anyone with the Guest [role](../../permissions.md) 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.

doc/user/permissions.md

@@ -434,7 +434,7 @@ Be aware that this regex could lead to a
 
 ## Free Guest users **(ULTIMATE)**
 
-When a user is given Guest permissions on a project, group, or both, and holds no
+When a user is given the Guest role on a project, group, or both, and holds no
 higher permission level on any other project or group on the GitLab instance,
 the user is considered a guest user by GitLab and does not consume a license seat.
 There is no other specific "guest" designation for newly created users.

doc/user/project/issue_board.md

@@ -594,7 +594,7 @@ You can move issues and lists by dragging them.
 
 Prerequisites:
 
-- A minimum of [Reporter](../permissions.md#project-members-permissions) access to a project in GitLab.
+- You must have at least the Reporter [role](../permissions.md#project-members-permissions) 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).

doc/user/project/issues/associate_zoom_meeting.md

@@ -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 [Reporter permissions](../../permissions.md),
+If the Zoom meeting URL is valid and you have at least the Reporter [role](../../permissions.md),
 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 [Reporter permissions](../../permissions.md),
+If you have at least the Reporter [role](../../permissions.md),
 a system alert notifies you that the meeting URL was successfully removed.

doc/user/project/issues/confidential_issues.md

@@ -77,14 +77,14 @@ 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 [Reporter access](../../permissions.md#project-members-permissions). However, a guest user can also create
+least the Reporter [role](../../permissions.md#project-members-permissions). However, a guest user can also create
 confidential issues, but can only view the ones that they created themselves.
 
 Confidential issues are also hidden in search results for unprivileged users.
-For example, here's what a user with the [Maintainer role](../../permissions.md) and Guest access
+For example, here's what a user with the [Maintainer role](../../permissions.md) and the Guest role
 sees in the project's search results respectively.
 
-| Maintainer role                                                                        | Guest access                                                                     |
+| Maintainer role                                                                        | Guest role                                                                     |
 |:---------------------------------------------------------------------------------------|:---------------------------------------------------------------------------------|
 | ![Confidential issues search by maintainer](img/confidential_issues_search_master.png) | ![Confidential issues search by guest](img/confidential_issues_search_guest.png) |
 

doc/user/project/issues/due_dates.md

@@ -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 [Reporter permissions](../../permissions.md)
+shipped on time. Users need at least the Reporter [role](../../permissions.md)
 to be able to edit the due date. All users with permission to view
 the issue can view the due date.
 

doc/user/project/merge_requests/approvals/rules.md

@@ -167,7 +167,7 @@ for protected branches. **(PREMIUM)**
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/40491) in GitLab 13.4.
 > - Moved to GitLab Premium in 13.9.
 
-You may need to grant users with [Reporter permissions](../../../permissions.md#project-members-permissions),
+You may have to grant users with the Reporter [role](../../../permissions.md#project-members-permissions)
 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

doc/user/project/merge_requests/authorization_for_merge_requests.md

@@ -40,7 +40,7 @@ protected branch.
 ## Forking workflow
 
 With the forking workflow, maintainers get the [Maintainer role](../../permissions.md) and regular
-developers get Reporter access to the authoritative repository, which prohibits
+developers get the Reporter role on the authoritative repository, which prohibits
 them from pushing any changes to it.
 
 Developers create forks of the authoritative project and push their feature

doc/user/project/releases/index.md

@@ -716,11 +716,11 @@ In the API:
 
 ### View a release and download assets
 
-> [The Guest permission for read action was adjusted](https://gitlab.com/gitlab-org/gitlab/-/issues/335209) in GitLab 14.5.
+> [Changes were made to the Guest role access](https://gitlab.com/gitlab-org/gitlab/-/issues/335209) in GitLab 14.5.
 
-- Users with [Reporter role or above](../../../user/permissions.md#project-members-permissions)
+- Users with the [Reporter role or above](../../../user/permissions.md#project-members-permissions)
   have read and download access to the project releases.
-- Users with [Guest role](../../../user/permissions.md#project-members-permissions)
+- Users with the [Guest role](../../../user/permissions.md#project-members-permissions)
   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.