Add latest changes from gitlab-org/gitlab@master

13 files changed, 268 insertions, 136 deletions

diff --git a/doc/api/project_import_export.md b/doc/api/project_import_export.md
index b95f8c2984d..a4ad496b667 100644
--- a/doc/api/project_import_export.md
+++ b/doc/api/project_import_export.md
@@ -196,6 +196,65 @@ NOTE:
 The maximum import file size can be set by the Administrator, default is `0` (unlimited)..
 As an administrator, you can modify the maximum import file size. To do so, use the `max_import_size` option in the [Application settings API](settings.md#change-application-settings) or the [Admin UI](../user/admin_area/settings/account_and_limit_settings.md). Default [modified](https://gitlab.com/gitlab-org/gitlab/-/issues/251106) from 50MB to 0 in GitLab 13.8.
 
+## Import a file from a remote object storage
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/282503) in GitLab 13.12 in [Beta](https://about.gitlab.com/handbook/product/gitlab-the-product/#beta).
+
+This endpoint is behind a feature flag that is disabled by default.
+
+To enable this endpoint:
+
+```ruby
+Feature.enable(:import_project_from_remote_file)
+```
+
+To disable this endpoint:
+
+```ruby
+Feature.disable(:import_project_from_remote_file)
+```
+
+```plaintext
+POST /projects/remote-import
+```
+
+| Attribute         | Type           | Required | Description                              |
+| ----------------- | -------------- | -------- | ---------------------------------------- |
+| `namespace`       | integer/string | no       | The ID or path of the namespace to import the project to. Defaults to the current user's namespace. |
+| `name`            | string         | no       | The name of the project to import. If not provided, defaults to the path of the project. |
+| `url`             | string         | yes      | URL for the file to import. |
+| `path`            | string         | yes      | Name and path for the new project. |
+| `overwrite`       | boolean        | no       | Whether to overwrite a project with the same path when importing. Defaults to `false`. |
+| `override_params` | Hash           | no       | Supports all fields defined in the [Project API](projects.md). |
+
+The passed override parameters take precedence over all values defined in the export file.
+
+```shell
+curl --request POST \
+  --header "PRIVATE-TOKEN: <your_access_token>" \
+  --url "https://gitlab.example.com/api/v4/projects/remote-import" \
+  --data '{"url":"https://remoteobject/file?token=123123","path":"remote-project"}'
+```
+
+```json
+{
+  "id": 1,
+  "description": null,
+  "name": "remote-project",
+  "name_with_namespace": "Administrator / remote-project",
+  "path": "remote-project",
+  "path_with_namespace": "root/remote-project",
+  "created_at": "2018-02-13T09:05:58.023Z",
+  "import_status": "scheduled",
+  "correlation_id": "mezklWso3Za",
+  "failed_relations": [],
+  "import_error": null
+}
+```
+
+The `ContentType` header must return a valid number. The maximum file size is 10 gigabytes.
+The `ContentLength` header must be `application/gzip`.
+
 ## Import status
 
 Get the status of an import.
diff --git a/doc/development/i18n/externalization.md b/doc/development/i18n/externalization.md
index f3d09903108..b177a7e0138 100644
--- a/doc/development/i18n/externalization.md
+++ b/doc/development/i18n/externalization.md
@@ -795,6 +795,10 @@ aren't in the message with ID `1 pipeline`.
 
 ## Adding a new language
 
+A new language should only be added as an option in User Preferences once at least 10% of the
+strings have been translated and approved. Even though a larger number of strings may have been
+translated, only the approved translations display in the GitLab UI.
+
 NOTE:
 [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/221012) in GitLab 13.3:
 Languages with less than 2% of translations are not available in the UI.
diff --git a/doc/subscriptions/self_managed/index.md b/doc/subscriptions/self_managed/index.md
index db0d54ff14c..648ad0c70a5 100644
--- a/doc/subscriptions/self_managed/index.md
+++ b/doc/subscriptions/self_managed/index.md
@@ -48,8 +48,8 @@ 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/activating_deactivating_users.md#deactivating-a-user) and
-  [blocked users](../../user/admin_area/blocking_unblocking_users.md) 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#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
   count toward overages in the subscribed seat count.
 - Users who are [pending approval](../../user/admin_area/approving_users.md).
 - Members with Guest permissions on an Ultimate subscription.
@@ -183,7 +183,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/blocking_unblocking_users.md#blocking-a-user).
+1. Prune any inactive or unwanted users by [blocking them](../../user/admin_area/moderate_users.md#blocking-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.
 
diff --git a/doc/user/admin_area/activating_deactivating_users.md b/doc/user/admin_area/activating_deactivating_users.md
index 144ee2dbf98..cafc7caf981 100644
--- a/doc/user/admin_area/activating_deactivating_users.md
+++ b/doc/user/admin_area/activating_deactivating_users.md
@@ -1,69 +1,8 @@
 ---
-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'
 ---
 
-# Activating and deactivating users
+This document was moved to [another location](moderate_users.md).
 
-GitLab administrators can deactivate and activate users.
-
-## Deactivating 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_unblocking_users.md),
-with the following differences:
-
-- It does not prohibit the user from logging back in via the UI.
-- Once a deactivated user logs back into the GitLab UI, their account is set to active.
-
-A deactivated user:
-
-- Cannot access Git repositories or the API.
-- Will not receive any notifications from GitLab.
-- Will not be able to use [slash commands](../../integration/slash_commands.md).
-
-Personal projects, and group and user history of the deactivated user will be left intact.
-
-A user can be deactivated from the Admin Area. To do this:
-
-1. Navigate to  **Admin Area > Overview > Users**.
-1. Select a user.
-1. Under the **Account** tab, click **Deactivate user**.
-
-Please note that for the deactivation option to be visible to an admin, the user:
-
-- Must be currently active.
-- Must not have signed in, or have any activity, in the last 90 days.
-
-Users can also be deactivated using the [GitLab API](../../api/users.md#deactivate-user).
-
-NOTE:
-A deactivated user does not consume a [seat](../../subscriptions/self_managed/index.md#billable-users).
-
-## Activating a user
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/22257) in GitLab 12.4.
-
-A deactivated user can be activated from the Admin Area.
-
-To do this:
-
-1. Navigate to  **Admin Area > Overview > Users**.
-1. Click on the **Deactivated** tab.
-1. Select a user.
-1. Under the **Account** tab, click **Activate user**.
-
-Users can also be activated using the [GitLab API](../../api/users.md#activate-user).
-
-NOTE:
-Activating a user changes the user's state to active and consumes a
-[seat](../../subscriptions/self_managed/index.md#billable-users).
-
-NOTE:
-A deactivated user can also activate their account themselves by logging back in via the UI.
+<!-- This redirect file can be deleted after <2021-08-12>. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->
diff --git a/doc/user/admin_area/approving_users.md b/doc/user/admin_area/approving_users.md
index 9141d7f488d..2b3b90cb1a4 100644
--- a/doc/user/admin_area/approving_users.md
+++ b/doc/user/admin_area/approving_users.md
@@ -21,7 +21,7 @@ When a user registers for an account while this setting is enabled:
 
 A user pending approval:
 
-- Is functionally identical to a [blocked](blocking_unblocking_users.md) user.
+- 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.
diff --git a/doc/user/admin_area/blocking_unblocking_users.md b/doc/user/admin_area/blocking_unblocking_users.md
index 14a5b5085cb..cafc7caf981 100644
--- a/doc/user/admin_area/blocking_unblocking_users.md
+++ b/doc/user/admin_area/blocking_unblocking_users.md
@@ -1,51 +1,8 @@
 ---
-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'
 ---
 
-# Blocking and unblocking users
+This document was moved to [another location](moderate_users.md).
 
-GitLab administrators block and unblock users.
-
-## Blocking a user
-
-In order to completely prevent access of a user to the GitLab instance, administrators can choose to
-block the user.
-
-Users can be blocked [via an abuse report](review_abuse_reports.md#blocking-users),
-or directly from the Admin Area. To do this:
-
-1. Navigate to  **Admin Area > Overview > Users**.
-1. Select a user.
-1. Under the **Account** tab, click **Block user**.
-
-A blocked user:
-
-- Cannot log in.
-- Cannot access Git repositories or the API.
-- Does not receive any notifications from GitLab.
-- Cannot use [slash commands](../../integration/slash_commands.md).
-
-Personal projects, and group and user history of the blocked user are left intact.
-
-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
-
-A blocked user can be unblocked from the Admin Area. To do this:
-
-1. Navigate to  **Admin Area > Overview > Users**.
-1. Click on the **Blocked** tab.
-1. Select a user.
-1. Under the **Account** tab, click **Unblock user**.
-
-Users can also be unblocked using the [GitLab API](../../api/users.md#unblock-user).
-
-NOTE:
-Unblocking a user changes the user's state to active and consumes a
-[seat](../../subscriptions/self_managed/index.md#billable-users).
+<!-- This redirect file can be deleted after <2021-08-12>. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->
diff --git a/doc/user/admin_area/index.md b/doc/user/admin_area/index.md
index b0a84d981c9..5d1fde1c767 100644
--- a/doc/user/admin_area/index.md
+++ b/doc/user/admin_area/index.md
@@ -117,8 +117,8 @@ To list users matching a specific criteria, click on one of the following tabs o
 - **2FA Enabled**
 - **2FA Disabled**
 - **External**
-- **[Blocked](blocking_unblocking_users.md)**
-- **[Deactivated](activating_deactivating_users.md)**
+- **[Blocked](moderate_users.md#blocking-a-user)**
+- **[Deactivated](moderate_users.md#deactivating-a-user)**
 - **Without projects**
 
 For each user, the following are listed:
diff --git a/doc/user/admin_area/moderate_users.md b/doc/user/admin_area/moderate_users.md
new file mode 100644
index 00000000000..c04003dd75f
--- /dev/null
+++ b/doc/user/admin_area/moderate_users.md
@@ -0,0 +1,157 @@
+---
+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
+---
+
+# Moderate users
+
+GitLab administrators can moderate user access by blocking, banning, or deactivating users.
+
+## Blocking and unblocking users
+
+GitLab administrators can block and unblock users.
+
+### Blocking a user
+
+In order to completely prevent access of a user to the GitLab instance,
+administrators can choose to block the user.
+
+Users can be blocked [via an abuse report](review_abuse_reports.md#blocking-users),
+or directly from the Admin Area. To do this:
+
+1. Navigate to  **Admin Area > Overview > Users**.
+1. Select a user.
+1. Under the **Account** tab, click **Block user**.
+
+A blocked user:
+
+- Cannot log in.
+- Cannot access Git repositories or the API.
+- Does not receive any notifications from GitLab.
+- Cannot use [slash commands](../../integration/slash_commands.md).
+
+Personal projects, and group and user history of the blocked user are left intact.
+
+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
+
+A blocked user can be unblocked from the Admin Area. To do this:
+
+1. Navigate to  **Admin Area > Overview > Users**.
+1. Click on the **Blocked** tab.
+1. Select a user.
+1. Under the **Account** tab, click **Unblock user**.
+
+Users can also be unblocked using the [GitLab API](../../api/users.md#unblock-user).
+
+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
+
+GitLab administrators can deactivate and activate users.
+
+### Deactivating 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),
+with the following differences:
+
+- It does not prohibit the user from logging back in via the UI.
+- Once a deactivated user logs back into the GitLab UI, their account is set to active.
+
+A deactivated user:
+
+- Cannot access Git repositories or the API.
+- Will not receive any notifications from GitLab.
+- Will not be able to use [slash commands](../../integration/slash_commands.md).
+
+Personal projects, and group and user history of the deactivated user are left intact.
+
+A user can be deactivated from the Admin Area. To do this:
+
+1. Navigate to  **Admin Area > Overview > Users**.
+1. Select a user.
+1. Under the **Account** tab, click **Deactivate user**.
+
+Please note that for the deactivation option to be visible to an admin, the user:
+
+- Must be currently active.
+- Must not have signed in, or have any activity, in the last 90 days.
+
+Users can also be deactivated using the [GitLab API](../../api/users.md#deactivate-user).
+
+NOTE:
+A deactivated user does not consume a [seat](../../subscriptions/self_managed/index.md#billable-users).
+
+### Activating a user
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/22257) in GitLab 12.4.
+
+A deactivated user can be activated from the Admin Area.
+
+To do this:
+
+1. Navigate to  **Admin Area > Overview > Users**.
+1. Click on the **Deactivated** tab.
+1. Select a user.
+1. Under the **Account** tab, click **Activate user**.
+
+Users can also be activated using the [GitLab API](../../api/users.md#activate-user).
+
+NOTE:
+Activating a user changes the user's state to active and consumes a
+[seat](../../subscriptions/self_managed/index.md#billable-users).
+
+NOTE:
+A deactivated user can also activate their account themselves by logging back in via the UI.
+
+## Ban and unban users
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/327353) in GitLab 13.12.
+
+GitLab administrators can ban users.
+
+NOTE:
+This feature is behind a feature flag that is disabled by default. GitLab administrators 
+with access to the GitLab Rails console can [enable](../../administration/feature_flags.md)
+this feature for your GitLab instance.
+
+### Ban a user
+
+To completely block a user, administrators can choose to ban the user.
+
+Users can be banned using the Admin Area. To do this:
+
+1. Navigate to  **Admin Area > Overview > Users**.
+1. Select a user.
+1. Under the **Account** tab, click **Ban user**.
+
+NOTE:
+This feature is a work in progress. Currently, banning a user
+only blocks them and does not hide their comments or issues.
+This functionality will be implemented in follow up issues.
+
+### Unban a user
+
+A banned user can be unbanned using the Admin Area. To do this:
+
+1. Navigate to  **Admin Area > Overview > Users**.
+1. Click on the **Banned** tab.
+1. Select a user.
+1. Under the **Account** tab, click **Unban user**.
+
+NOTE:
+Unbanning a user changes the user's state to active and consumes a
+[seat](../../subscriptions/self_managed/index.md#billable-users).
diff --git a/doc/user/application_security/container_scanning/index.md b/doc/user/application_security/container_scanning/index.md
index 6848126e163..10d276bd224 100644
--- a/doc/user/application_security/container_scanning/index.md
+++ b/doc/user/application_security/container_scanning/index.md
@@ -501,29 +501,38 @@ For details on saving and transporting Docker images as a file, see Docker's doc
 
 #### Automating container scanning vulnerability database updates with a pipeline
 
-For those using Clair, it can be worthwhile to set up a [scheduled pipeline](../../../ci/pipelines/schedules.md)
-to build a new version of the vulnerabilities database on a preset schedule. Automating
-this with a pipeline means you do not have to do it manually each time. You can use the following
-`.gitlab-yml.ci` as a template:
+We recommend that you set up a [scheduled pipeline](../../../ci/pipelines/schedules.md)
+to fetch the latest vulnerabilities database on a preset schedule. Because the Clair scanner is
+deprecated, the latest vulnerabilities are currently only available for the Trivy scanner.
+Automating this with a pipeline means you do not have to do it manually each time. You can use the
+following `.gitlab-yml.ci` example as a template.
 
 ```yaml
-image: docker:stable
+variables:
+  # If using Clair, uncomment the following 2 lines and comment the Trivy lines below
+  # SOURCE_IMAGE: arminc/clair-db:latest
+  # TARGET_IMAGE: $CI_REGISTRY/$CI_PROJECT_PATH/clair-vulnerabilities-db
 
-stages:
-  - build
+  # If using Trivy, uncomment the following 3 lines and comment the Clair lines above
+  CS_MAJOR_VERSION: 4 # ensure that this value matches the one you use in your scanning jobs
+  SOURCE_IMAGE: registry.gitlab.com/gitlab-org/security-products/analyzers/container-scanning:$CS_MAJOR_VERSION
+  TARGET_IMAGE: $CI_REGISTRY/$CI_PROJECT_PATH/gitlab-container-scanning
 
-build_latest_vulnerabilities:
-  stage: build
+image: docker:stable
+
+update-vulnerabilities-db:
   services:
-    - docker:19.03.12-dind
+    - docker:19-dind
   script:
-    - docker pull arminc/clair-db:latest
-    - docker tag arminc/clair-db:latest $CI_REGISTRY/namespace/clair-vulnerabilities-db
-    - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" $CI_REGISTRY
-    - docker push $CI_REGISTRY/namespace/clair-vulnerabilities-db
+    - docker pull $SOURCE_IMAGE
+    - docker tag $SOURCE_IMAGE $TARGET_IMAGE
+    - echo "$CI_REGISTRY_PASSWORD" | docker login $CI_REGISTRY --username $CI_REGISTRY_USER --password-stdin
+    - docker push $TARGET_IMAGE
 ```
 
-The above template works for a GitLab Docker registry running on a local installation, however, if you're using a non-GitLab Docker registry, you need to change the `$CI_REGISTRY` value and the `docker login` credentials to match the details of your local registry.
+The above template works for a GitLab Docker registry running on a local installation. However, if
+you're using a non-GitLab Docker registry, you must change the `$CI_REGISTRY` value and the
+`docker login` credentials to match your local registry's details.
 
 ## Running the standalone container scanning tool
 
diff --git a/doc/user/application_security/vulnerabilities/index.md b/doc/user/application_security/vulnerabilities/index.md
index b96451fa67d..965b856504d 100644
--- a/doc/user/application_security/vulnerabilities/index.md
+++ b/doc/user/application_security/vulnerabilities/index.md
@@ -182,7 +182,7 @@ The following vulnerability scanners and their databases are regularly updated:
 
 | Secure scanning tool                                            | Vulnerabilities database updates |
 |:----------------------------------------------------------------|----------------------------------|
-| [Container Scanning](../container_scanning/index.md)            | Uses `clair`. The latest `clair-db` version is used for each job by running the [`latest` Docker image tag](https://gitlab.com/gitlab-org/gitlab/blob/438a0a56dc0882f22bdd82e700554525f552d91b/lib/gitlab/ci/templates/Security/Container-Scanning.gitlab-ci.yml#L37). The `clair-db` database [is updated daily according to the author](https://github.com/arminc/clair-local-scan#clair-server-or-local). |
+| [Container Scanning](../container_scanning/index.md)            | Uses either `trivy` or `clair`. For the `trivy` scanner, a job runs on a daily basis to build a new image with the latest vulnerability database updates from the [upstream `trivy-db`](https://github.com/aquasecurity/trivy-db). For the `clair` scanner, the latest `clair-db` version is used; `clair-db` database [is updated daily according to the author](https://github.com/arminc/clair-local-scan#clair-server-or-local). |
 | [Dependency Scanning](../dependency_scanning/index.md)          | Relies on `bundler-audit` (for Ruby gems), `retire.js` (for npm packages), and `gemnasium` (the GitLab tool for all libraries). Both `bundler-audit` and `retire.js` fetch their vulnerabilities data from GitHub repositories, so vulnerabilities added to `ruby-advisory-db` and `retire.js` are immediately available. The tools themselves are updated once per month if there's a new version. The [Gemnasium DB](https://gitlab.com/gitlab-org/security-products/gemnasium-db) is updated at least once a week. See our [current measurement of time from CVE being issued to our product being updated](https://about.gitlab.com/handbook/engineering/development/performance-indicators/#cve-issue-to-update). |
 | [Dynamic Application Security Testing (DAST)](../dast/index.md) | The scanning engine is updated on a periodic basis. See the [version of the underlying tool `zaproxy`](https://gitlab.com/gitlab-org/security-products/dast/blob/master/Dockerfile#L1). The scanning rules are downloaded at scan runtime. |
 | [Static Application Security Testing (SAST)](../sast/index.md)  | Relies exclusively on [the tools GitLab wraps](../sast/index.md#supported-languages-and-frameworks). The underlying analyzers are updated at least once per month if a relevant update is available. The vulnerabilities database is updated by the upstream tools. |
diff --git a/doc/user/packages/container_registry/index.md b/doc/user/packages/container_registry/index.md
index 3b0c59ac31c..6d7b009bb09 100644
--- a/doc/user/packages/container_registry/index.md
+++ b/doc/user/packages/container_registry/index.md
@@ -698,6 +698,13 @@ You can, however, remove the Container Registry for a project:
 
 The **Packages & Registries > Container Registry** entry is removed from the project's sidebar.
 
+## Manifest lists and garbage collection
+
+Manifest lists are commonly used for creating multi-architecture images. If you rely on manifest
+lists, you should tag all the individual manifests referenced by a list in their respective
+repositories, and not just the manifest list itself. This ensures that those manifests aren't
+garbage collected, as long as they have at least one tag pointing to them.
+
 ## Troubleshooting the GitLab Container Registry
 
 ### Docker connection error
diff --git a/doc/user/profile/account/delete_account.md b/doc/user/profile/account/delete_account.md
index c0560269f00..361353a0f8c 100644
--- a/doc/user/profile/account/delete_account.md
+++ b/doc/user/profile/account/delete_account.md
@@ -69,7 +69,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/blocking_unblocking_users.md)
+[blocking a user](../../admin_area/moderate_users.md#blocking-a-user)
 or using the **Delete user** option instead.
 
 When a user is deleted from an [abuse report](../../admin_area/review_abuse_reports.md)
diff --git a/doc/user/upgrade_email_bypass.md b/doc/user/upgrade_email_bypass.md
index 199c1a47e04..7d2f2395815 100644
--- a/doc/user/upgrade_email_bypass.md
+++ b/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/blocking_unblocking_users.md) by an administrator.
+You can assure your users that they have not been [Blocked](admin_area/moderate_users.md#blocking-and-unblocking-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?