Merge branch 'eread/refine-moderate-users-content' into 'master'

Refine moderate users content

See merge request gitlab-org/gitlab!66417

doc/.vale/gitlab/spelling-exceptions.txt

@@ -687,6 +687,7 @@ unary
 unassign
 unassigning
 unassigns
+unban
 uncheck
 unchecked
 unchecking

doc/api/settings.md

@@ -241,7 +241,7 @@ listed in the descriptions of the relevant settings.
 | `check_namespace_plan`                   | boolean          | no                                   | **(PREMIUM)** Enabling this makes only licensed EE features available to projects if the project namespace's plan includes the feature or if the project is public. |
 | `commit_email_hostname`                  | string           | no                                   | Custom hostname (for private commit emails). |
 | `container_registry_token_expire_delay`  | integer          | no                                   | Container Registry token duration in minutes. |
-| `deactivate_dormant_users`               | boolean          | no                                   | Enable [atomatic deactivation of dormant users](../user/admin_area/moderate_users.md#automatically-deactivate-dormant-users). |
+| `deactivate_dormant_users`               | boolean          | no                                   | Enable [automatic deactivation of dormant users](../user/admin_area/moderate_users.md#automatically-deactivate-dormant-users). |
 | `default_artifacts_expire_in`            | string           | no                                   | Set the default expiration time for each job's artifacts. |
 | `default_branch_protection`              | integer          | no                                   | Determine if developers can push to the default branch. Can take: `0` _(not protected, both developers and maintainers can push new commits, force push, or delete the branch)_, `1` _(partially protected, developers and maintainers can push new commits, but cannot force push, or delete, the branch)_ or `2` _(fully protected, developers cannot push new commits, but maintainers can; no-one can force push or delete the branch)_ as a parameter. Default is `2`. |
 | `default_ci_config_path`                  | string           | no                                   | Default CI/CD configuration file and path for new projects (`.gitlab-ci.yml` if not set). |
@@ -370,7 +370,7 @@ listed in the descriptions of the relevant settings.
 | `repository_size_limit`                  | integer          | no                                   | **(PREMIUM)** Size limit per repository (MB) |
 | `repository_storages_weighted`           | hash of strings to integers | no                        | (GitLab 13.1 and later) Hash of names of taken from `gitlab.yml` to [weights](../administration/repository_storage_paths.md#configure-where-new-repositories-are-stored). New projects are created in one of these stores, chosen by a weighted random selection. |
 | `repository_storages`                    | array of strings | no                                   | (GitLab 13.0 and earlier) List of names of enabled storage paths, taken from `gitlab.yml`. New projects are created in one of these stores, chosen at random. |
-| `require_admin_approval_after_user_signup` | boolean        | no                                   | When enabled, any user that signs up for an account using the registration form is placed under a **Pending approval** state and has to be explicitly [approved](../user/admin_area/approving_users.md) by an administrator. |
+| `require_admin_approval_after_user_signup` | boolean        | no                                   | When enabled, any user that signs up for an account using the registration form is placed under a **Pending approval** state and has to be explicitly [approved](../user/admin_area/moderate_users.md) by an administrator. |
 | `require_two_factor_authentication`      | boolean          | no                                   | (**If enabled, requires:** `two_factor_grace_period`) Require all users to set up Two-factor authentication. |
 | `restricted_visibility_levels`           | array of strings | no                                   | Selected levels cannot be used by non-Administrator users for groups, projects or snippets. Can take `private`, `internal` and `public` as a parameter. Default is `null` which means there is no restriction. |
 | `rsa_key_restriction`                    | integer          | no                                   | The minimum allowed bit length of an uploaded RSA key. Default is `0` (no restriction). `-1` disables RSA keys. |

doc/subscriptions/self_managed/index.md

@@ -48,12 +48,15 @@ using [Seat Link](#seat-link).
 A _billable user_ counts against the number of subscription seats. Every user is considered a
 billable user, with the following exceptions:
 
-- [Deactivated users](../../user/admin_area/moderate_users.md#deactivating-a-user) and
-  [blocked users](../../user/admin_area/moderate_users.md#blocking-a-user) don't count as billable users in the current subscription. When they are either deactivated or blocked they release a _billable user_ seat. However, they may
+- [Deactivated users](../../user/admin_area/moderate_users.md#deactivate-a-user) and
+  [blocked users](../../user/admin_area/moderate_users.md#block-a-user) don't count as billable users in the current subscription. When they are either deactivated or blocked they release a _billable user_ seat. However, they may
   count toward overages in the subscribed seat count.
-- Users who are [pending approval](../../user/admin_area/approving_users.md).
+- Users who are [pending approval](../../user/admin_area/moderate_users.md#users-pending-approval).
 - Members with Guest permissions on an Ultimate subscription.
-- GitLab-created service accounts: `Ghost User` and bots [(`Support Bot`](../../user/project/service_desk.md#support-bot-user), [`Project bot users`](../../user/project/settings/project_access_tokens.md#project-bot-users), and so on).
+- GitLab-created service accounts: `Ghost User` and bots
+  ([`Support Bot`](../../user/project/service_desk.md#support-bot-user),
+  [`Project bot users`](../../user/project/settings/project_access_tokens.md#project-bot-users), and
+  so on.)
 
 ### Tips for managing users and subscription seats
 
@@ -183,7 +186,7 @@ Starting 30 days before a subscription expires, GitLab notifies administrators o
 
 We recommend following these steps during renewal:
 
-1. Prune any inactive or unwanted users by [blocking them](../../user/admin_area/moderate_users.md#blocking-a-user).
+1. Prune any inactive or unwanted users by [blocking them](../../user/admin_area/moderate_users.md#block-a-user).
 1. Determine if you have a need for user growth in the upcoming subscription.
 1. Log in to the [Customers Portal](https://customers.gitlab.com/customers/sign_in) and select the **Renew** button beneath your existing subscription.
 

doc/user/admin_area/approving_users.md

 ---
-stage: Manage
-group: Access
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
-type: howto
+redirect_to: 'moderate_users.md'
+remove_date: '2021-10-20'
 ---
 
-# Users pending approval
+This document was moved to [another location](moderate_users.md).
 
-A user in _pending approval_ state requires action by an administrator. A user sign up can be in a
-pending approval state because an administrator has enabled either, or both, of the following
-options:
-
-- [Require admin approval for new sign-ups](settings/sign_up_restrictions.md#require-administrator-approval-for-new-sign-ups) setting.
-- [User cap](settings/sign_up_restrictions.md#user-cap).
-
-When a user registers for an account while this setting is enabled:
-
-- The user is placed in a **Pending approval** state.
-- The user sees a message telling them their account is awaiting approval by an administrator.
-
-A user pending approval:
-
-- Is functionally identical to a [blocked](moderate_users.md#blocking-a-user) user.
-- Cannot sign in.
-- Cannot access Git repositories or the GitLab API.
-- Does not receive any notifications from GitLab.
-- Does not consume a [seat](../../subscriptions/self_managed/index.md#billable-users).
-
-An administrator must [approve their sign up](#approve-or-reject-a-user-sign-up) to allow them to
-sign in.
-
-## View user sign ups pending approval
-
-To view user sign ups pending approval:
-
-1. On the top bar, select **Menu >** **{admin}** **Admin**.
-1. On the left sidebar, select **Overview > Users**.
-1. Select the **Pending approval** tab.
-
-## Approve or reject a user sign up
-
-A user sign up pending approval can be approved or rejected from the Admin Area.
-
-To approve or reject a user sign up:
-
-1. On the top bar, select **Menu >** **{admin}** **Admin**.
-1. On the left sidebar, select **Overview > Users**.
-1. Select the **Pending approval** tab.
-1. (Optional) Select a user.
-1. Select the **{settings}** **User administration** dropdown.
-1. Select **Approve** or **Reject**.
-
-Approving a user:
-
-- Activates their account.
-- Changes the user's state to active.
-- Consumes a subscription [seat](../../subscriptions/self_managed/index.md#billable-users).
+<!-- This redirect file can be deleted after <2021-10-20>. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->

doc/user/admin_area/index.md

@@ -121,8 +121,8 @@ To list users matching a specific criteria, click on one of the following tabs o
 - **2FA Enabled**
 - **2FA Disabled**
 - **External**
-- **[Blocked](moderate_users.md#blocking-a-user)**
-- **[Deactivated](moderate_users.md#deactivating-a-user)**
+- **[Blocked](moderate_users.md#block-a-user)**
+- **[Deactivated](moderate_users.md#deactivate-a-user)**
 - **Without projects**
 
 For each user, the following are listed:

doc/user/admin_area/moderate_users.md

@@ -7,13 +7,66 @@ type: howto
 
 # Moderate users
 
-GitLab administrators can moderate user access by blocking, banning, or deactivating users.
+GitLab administrators can moderate user access by approving, blocking, banning, or deactivating
+users.
 
-## Blocking and unblocking users
+## Users pending approval
+
+A user in _pending approval_ state requires action by an administrator. A user sign up can be in a
+pending approval state because an administrator has enabled either, or both, of the following
+options:
+
+- [Require admin approval for new sign-ups](settings/sign_up_restrictions.md#require-administrator-approval-for-new-sign-ups) setting.
+- [User cap](settings/sign_up_restrictions.md#user-cap).
+
+When a user registers for an account while this setting is enabled:
+
+- The user is placed in a **Pending approval** state.
+- The user sees a message telling them their account is awaiting approval by an administrator.
+
+A user pending approval:
+
+- Is functionally identical to a [blocked](#block-a-user) user.
+- Cannot sign in.
+- Cannot access Git repositories or the GitLab API.
+- Does not receive any notifications from GitLab.
+- Does not consume a [seat](../../subscriptions/self_managed/index.md#billable-users).
+
+An administrator must [approve their sign up](#approve-or-reject-a-user-sign-up) to allow them to
+sign in.
+
+### View user sign ups pending approval
+
+To view user sign ups pending approval:
+
+1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the left sidebar, select **Overview > Users**.
+1. Select the **Pending approval** tab.
+
+### Approve or reject a user sign up
+
+A user sign up pending approval can be approved or rejected from the Admin Area.
+
+To approve or reject a user sign up:
+
+1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the left sidebar, select **Overview > Users**.
+1. Select the **Pending approval** tab.
+1. (Optional) Select a user.
+1. Select the **{settings}** **User administration** dropdown.
+1. Select **Approve** or **Reject**.
+
+Approving a user:
+
+- Activates their account.
+- Changes the user's state to active.
+- Consumes a subscription [seat](../../subscriptions/self_managed/index.md#billable-users).
+
+## Block and unblock users
 
 GitLab administrators can block and unblock users.
 
-### Blocking a user
+### Block a user
 
 In order to completely prevent access of a user to the GitLab instance,
 administrators can choose to block the user.
@@ -41,7 +94,7 @@ Users can also be blocked using the [GitLab API](../../api/users.md#block-user).
 NOTE:
 A blocked user does not consume a [seat](../../subscriptions/self_managed/index.md#billable-users).
 
-### Unblocking a user
+### Unblock a user
 
 A blocked user can be unblocked from the Admin Area. To do this:
 
@@ -58,18 +111,18 @@ NOTE:
 Unblocking a user changes the user's state to active and consumes a
 [seat](../../subscriptions/self_managed/index.md#billable-users).
 
-## Activating and deactivating users
+## Activate and deactivate users
 
 GitLab administrators can deactivate and activate users.
 
-### Deactivating a user
+### Deactivate a user
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/22257) in GitLab 12.4.
 
 In order to temporarily prevent access by a GitLab user that has no recent activity,
 administrators can choose to deactivate the user.
 
-Deactivating a user is functionally identical to [blocking a user](#blocking-and-unblocking-users),
+Deactivating a user is functionally identical to [blocking a user](#block-and-unblock-users),
 with the following differences:
 
 - It does not prohibit the user from logging back in via the UI.
@@ -118,7 +171,7 @@ When this feature is enabled, GitLab runs a job once a day to deactivate the dor
 
 A maximum of 100,000 users can be deactivated per day.
 
-### Activating a user
+### Activate a user
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/22257) in GitLab 12.4.
 

doc/user/admin_area/settings/sign_up_restrictions.md

@@ -31,7 +31,10 @@ To disable sign ups:
 > - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/4491) in GitLab 13.5.
 > - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/267568) in GitLab 13.6.
 
-When this setting is enabled, any user visiting your GitLab domain and signing up for a new account must be explicitly [approved](../approving_users.md#approve-or-reject-a-user-sign-up) by an administrator before they can start using their account. In GitLab 13.6 and later, this setting is enabled by default for new GitLab instances. It is only applicable if sign ups are enabled.
+When this setting is enabled, any user visiting your GitLab domain and signing up for a new account
+must be explicitly [approved](../moderate_users.md#approve-or-reject-a-user-sign-up) by an
+administrator before they can start using their account. In GitLab 13.6 and later, this setting is
+enabled by default for new GitLab instances. It is only applicable if sign ups are enabled.
 
 To require administrator approval for new sign ups:
 
@@ -59,7 +62,7 @@ To enforce confirmation of the email address used for new sign ups:
 > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/292600) in GitLab 13.9.
 
 When the number of billable users reaches the user cap, any user who is added or requests access must be
-[approved](../approving_users.md#approve-or-reject-a-user-sign-up) by an administrator before they can start using
+[approved](../moderate_users.md#approve-or-reject-a-user-sign-up) by an administrator before they can start using
 their account.
 
 If an administrator [increases](#set-the-user-cap-number) or [removes](#remove-the-user-cap) the

doc/user/profile/account/delete_account.md

@@ -70,7 +70,7 @@ username of the original user.
 When using the **Delete user and contributions** option, **all** associated records
 are removed. This includes all of the items mentioned above including issues,
 merge requests, notes/comments, and more. Consider
-[blocking a user](../../admin_area/moderate_users.md#blocking-a-user)
+[blocking a user](../../admin_area/moderate_users.md#block-a-user)
 or using the **Delete user** option instead.
 
 When a user is deleted from an [abuse report](../../admin_area/review_abuse_reports.md)

doc/user/upgrade_email_bypass.md

@@ -73,7 +73,7 @@ Your account has been blocked. Fatal: Could not read from remote repository
 Your primary email address is not confirmed.
 ```
 
-You can assure your users that they have not been [Blocked](admin_area/moderate_users.md#blocking-and-unblocking-users) by an administrator.
+You can assure your users that they have not been [Blocked](admin_area/moderate_users.md#block-and-unblock-users) by an administrator.
 When affected users see this message, they must confirm their email address before they can commit code.
 
 ## What do I need to know as an administrator of a GitLab self-managed Instance?