diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2023-03-30 21:10:57 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2023-03-30 21:10:57 +0300 |
commit | b48bbc842d4baf2ba16bd8c4db9a924324b7f13a (patch) | |
tree | 240c25c78d10e517d31ebfac78551949a3f2fe1f /doc/user | |
parent | 93501e7509fb61b25f091d81381d3e86842a9cdd (diff) |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc/user')
-rw-r--r-- | doc/user/application_security/sast/customize_rulesets.md | 2 | ||||
-rw-r--r-- | doc/user/clusters/agent/ci_cd_workflow.md | 14 | ||||
-rw-r--r-- | doc/user/group/saml_sso/index.md | 166 | ||||
-rw-r--r-- | doc/user/infrastructure/iac/terraform_state.md | 5 | ||||
-rw-r--r-- | doc/user/packages/yarn_repository/index.md | 6 | ||||
-rw-r--r-- | doc/user/project/changelogs.md | 4 | ||||
-rw-r--r-- | doc/user/project/deploy_keys/index.md | 1 | ||||
-rw-r--r-- | doc/user/project/import/bitbucket_server.md | 3 | ||||
-rw-r--r-- | doc/user/project/import/gitlab_com.md | 6 | ||||
-rw-r--r-- | doc/user/project/index.md | 8 | ||||
-rw-r--r-- | doc/user/project/integrations/microsoft_teams.md | 2 | ||||
-rw-r--r-- | doc/user/project/merge_requests/approvals/settings.md | 2 | ||||
-rw-r--r-- | doc/user/project/merge_requests/merge_when_pipeline_succeeds.md | 8 | ||||
-rw-r--r-- | doc/user/project/system_notes.md | 2 | ||||
-rw-r--r-- | doc/user/public_access.md | 3 | ||||
-rw-r--r-- | doc/user/report_abuse.md | 3 |
16 files changed, 113 insertions, 122 deletions
diff --git a/doc/user/application_security/sast/customize_rulesets.md b/doc/user/application_security/sast/customize_rulesets.md index d070883df9a..b45b25db69f 100644 --- a/doc/user/application_security/sast/customize_rulesets.md +++ b/doc/user/application_security/sast/customize_rulesets.md @@ -323,7 +323,7 @@ With the following custom ruleset configuration, vulnerabilities found with [semgrep] [[semgrep.ruleset]] [semgrep.ruleset.identifier] - type = "CWE" + type = "cwe" value = "322" [semgrep.ruleset.override] severity = "Critical" diff --git a/doc/user/clusters/agent/ci_cd_workflow.md b/doc/user/clusters/agent/ci_cd_workflow.md index abbcb533e7e..60c36b35b53 100644 --- a/doc/user/clusters/agent/ci_cd_workflow.md +++ b/doc/user/clusters/agent/ci_cd_workflow.md @@ -7,7 +7,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w # Using GitLab CI/CD with a Kubernetes cluster **(FREE)** > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/327409) in GitLab 14.1. -> - The pre-configured `KUBECONFIG` was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/324275) in GitLab 14.2. +> - The pre-configured variable `$KUBECONFIG` [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/324275) in GitLab 14.2. > - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/5784) the `ci_access` attribute in GitLab 14.3. > - The ability to authorize groups was [introduced](https://gitlab.com/groups/gitlab-org/-/epics/5784) in GitLab 14.3. > - [Moved](https://gitlab.com/groups/gitlab-org/-/epics/6290) to GitLab Free in 14.5. @@ -78,7 +78,8 @@ To authorize the agent to access the GitLab project where you keep Kubernetes ma - You can install additional agents into the same cluster to accommodate additional hierarchies. - You can authorize up to 100 projects. -All CI/CD jobs now include a `KUBECONFIG` with contexts for every shared agent connection. +All CI/CD jobs now include a `kubeconfig` file with contexts for every shared agent connection. +The `kubeconfig` path is available in the environment variable `$KUBECONFIG`. Choose the context to run `kubectl` commands from your CI/CD scripts. ### Authorize the agent to access projects in your groups @@ -104,7 +105,8 @@ To authorize the agent to access all of the GitLab projects in a group or subgro - You can authorize up to 100 groups. All the projects that belong to the group and its subgroups are now authorized to access the agent. -All CI/CD jobs now include a `KUBECONFIG` with contexts for every shared agent connection. +All CI/CD jobs now include a `kubeconfig` file with contexts for every shared agent connection. +The `kubeconfig` path is available in an environment variable `$KUBECONFIG`. Choose the context to run `kubectl` commands from your CI/CD scripts. ## Update your `.gitlab-ci.yml` file to run `kubectl` commands @@ -159,10 +161,10 @@ When you deploy to an environment that has both a - The certificate-based cluster's context is called `gitlab-deploy`. This context is always selected by default. -- In GitLab 14.9 and later, agent contexts are included in the - `KUBECONFIG`. You can select them by using `kubectl config use-context path/to/agent/repository:agent-name`. +- In GitLab 14.9 and later, agent contexts are included in `$KUBECONFIG`. + You can select them by using `kubectl config use-context path/to/agent/repository:agent-name`. - In GitLab 14.8 and earlier, you can still use agent connections, but for environments that - already have a certificate-based cluster, the agent connections are not included in the `KUBECONFIG`. + already have a certificate-based cluster, the agent connections are not included in `$KUBECONFIG`. To use an agent connection when certificate-based connections are present, you can manually configure a new `kubectl` configuration context. For example: diff --git a/doc/user/group/saml_sso/index.md b/doc/user/group/saml_sso/index.md index 1af95b06aa8..37f1f4cc65e 100644 --- a/doc/user/group/saml_sso/index.md +++ b/doc/user/group/saml_sso/index.md @@ -235,81 +235,6 @@ The certificate [fingerprint algorithm](../../../integration/saml.md#configure-s If you are having issues configuring GitLab, see the [troubleshooting documentation](#troubleshooting). -### SSO enforcement - -> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/5291) in GitLab 11.8. -> - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/9255) in GitLab 11.11 with ongoing enforcement in the GitLab UI. -> - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/292811) in GitLab 13.8, with an updated timeout experience. -> - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/211962) in GitLab 13.8 with allowing group owners to not go through SSO. -> - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/9152) in GitLab 13.11 with enforcing open SSO session to use Git if this setting is switched on. -> - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/339888) in GitLab 14.7 to not enforce SSO checks for Git activity originating from CI/CD jobs. -> - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/215155) in GitLab 15.5 [with a flag](../../../administration/feature_flags.md) named `transparent_sso_enforcement` to include transparent enforcement even when SSO enforcement is not enabled. Disabled on GitLab.com. -> - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/375788) in GitLab 15.8 by enabling transparent SSO by default on GitLab.com. -> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/389562) in GitLab 15.10. Feature flag `transparent_sso_enforcement` removed. - -On GitLab.com, SSO is enforced: - -- When SAML SSO is enabled. -- For users with an existing SAML identity when accessing groups and projects in the organization's - group hierarchy. Users can view other groups and projects as well as their user settings without SSO sign in by using their GitLab.com credentials. - -A user has a SAML identity if one or both of the following are true: - -- They have signed in to GitLab by using their GitLab group's single sign-on URL. -- They were provisioned by SCIM. - -Users are not prompted to sign in through SSO on each visit. GitLab checks -whether a user has authenticated through SSO. If the user last signed in more -than 24 hours ago, GitLab prompts the user to sign in again through SSO. - -SSO is enforced as follows: - -| Project/Group visibility | Enforce SSO setting | Member with identity | Member without identity | Non-member or not signed in | -|--------------------------|---------------------|--------------------| ------ |------------------------------| -| Private | Off | Enforced | Not enforced | No access | -| Private | On | Enforced | Enforced | No access | -| Public | Off | Enforced | Not enforced | Not enforced | -| Public | On | Enforced | Enforced | Not enforced | - -An [issue exists](https://gitlab.com/gitlab-org/gitlab/-/issues/297389) to add a similar SSO requirement for API activity. - -#### SSO-only for web activity enforcement - -When the **Enforce SSO-only authentication for web activity for this group** option is enabled: - -- All users must access GitLab by using their GitLab group's single sign-on URL - to access group resources, regardless of whether they have an existing SAML - identity. -- SSO is enforced when users access groups and projects in the organization's - group hierarchy. Users can view other groups and projects without SSO sign in. -- Users cannot be added as new members manually. -- Users with the Owner role can use the standard sign in process to make - necessary changes to top-level group settings. - -SSO enforcement for web activity has the following effects when enabled: - -- For groups, users cannot share a project in the group outside the top-level - group, even if the project is forked. -- Git activity originating from CI/CD jobs do not have the SSO check enforced. -- Credentials that are not tied to regular users (for example, project and group - access tokens, and deploy keys) do not have the SSO check enforced. -- Users must be signed-in through SSO before they can pull images using the - [Dependency Proxy](../../packages/dependency_proxy/index.md). -- When the **Enforce SSO-only authentication for Git and Dependency Proxy - activity for this group** option is enabled, any API endpoint that involves - Git activity is under SSO enforcement. For example, creating or deleting a - branch, commit, or tag. For Git activity over SSH and HTTPS, users must - have at least one active session signed-in through SSO before they can push to or - pull from a GitLab repository. - -When SSO for web activity is enforced, non-SSO group members do not lose access -immediately. If the user: - -- Has an active session, they can continue accessing the group for up to 24 - hours until the identity provider session times out. -- Is signed out, they cannot access the group after being removed from the - identity provider. - ## User access and management > - SAML user provisioning [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/268142) in GitLab 13.7. @@ -478,10 +403,6 @@ For example, to unlink the `MyOrg` account: For information on automatically managing GitLab group membership, see [SAML Group Sync](group_sync.md). -## Passwords for users created via SAML SSO for Groups - -The [Generated passwords for users created through integrated authentication](../../../security/passwords_for_integrated_authentication_methods.md) guide provides an overview of how GitLab generates and sets passwords for users created via SAML SSO for Groups. - ## NameID GitLab.com uses the SAML **NameID** to identify users. The **NameID** is: @@ -517,16 +438,87 @@ requires a different format. You can use any format except `Transient`. -## Related topics +## SSO enforcement + +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/5291) in GitLab 11.8. +> - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/9255) in GitLab 11.11 with ongoing enforcement in the GitLab UI. +> - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/292811) in GitLab 13.8, with an updated timeout experience. +> - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/211962) in GitLab 13.8 with allowing group owners to not go through SSO. +> - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/9152) in GitLab 13.11 with enforcing open SSO session to use Git if this setting is switched on. +> - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/339888) in GitLab 14.7 to not enforce SSO checks for Git activity originating from CI/CD jobs. +> - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/215155) in GitLab 15.5 [with a flag](../../../administration/feature_flags.md) named `transparent_sso_enforcement` to include transparent enforcement even when SSO enforcement is not enabled. Disabled on GitLab.com. +> - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/375788) in GitLab 15.8 by enabling transparent SSO by default on GitLab.com. +> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/389562) in GitLab 15.10. Feature flag `transparent_sso_enforcement` removed. + +On GitLab.com, SSO is enforced: + +- When SAML SSO is enabled. +- For users with an existing SAML identity when accessing groups and projects in the organization's + group hierarchy. Users can view other groups and projects as well as their user settings without SSO sign in by using their GitLab.com credentials. + +A user has a SAML identity if one or both of the following are true: + +- They have signed in to GitLab by using their GitLab group's single sign-on URL. +- They were provisioned by SCIM. + +Users are not prompted to sign in through SSO on each visit. GitLab checks +whether a user has authenticated through SSO. If the user last signed in more +than 24 hours ago, GitLab prompts the user to sign in again through SSO. + +SSO is enforced as follows: + +| Project/Group visibility | Enforce SSO setting | Member with identity | Member without identity | Non-member or not signed in | +|--------------------------|---------------------|--------------------| ------ |------------------------------| +| Private | Off | Enforced | Not enforced | No access | +| Private | On | Enforced | Enforced | No access | +| Public | Off | Enforced | Not enforced | Not enforced | +| Public | On | Enforced | Enforced | Not enforced | + +An [issue exists](https://gitlab.com/gitlab-org/gitlab/-/issues/297389) to add a similar SSO requirement for API activity. -For more information on: +### SSO-only for web activity enforcement + +When the **Enforce SSO-only authentication for web activity for this group** option is enabled: + +- All users must access GitLab by using their GitLab group's single sign-on URL + to access group resources, regardless of whether they have an existing SAML + identity. +- SSO is enforced when users access groups and projects in the organization's + group hierarchy. Users can view other groups and projects without SSO sign in. +- Users cannot be added as new members manually. +- Users with the Owner role can use the standard sign in process to make + necessary changes to top-level group settings. + +SSO enforcement for web activity has the following effects when enabled: + +- For groups, users cannot share a project in the group outside the top-level + group, even if the project is forked. +- Git activity originating from CI/CD jobs do not have the SSO check enforced. +- Credentials that are not tied to regular users (for example, project and group + access tokens, and deploy keys) do not have the SSO check enforced. +- Users must be signed-in through SSO before they can pull images using the + [Dependency Proxy](../../packages/dependency_proxy/index.md). +- When the **Enforce SSO-only authentication for Git and Dependency Proxy + activity for this group** option is enabled, any API endpoint that involves + Git activity is under SSO enforcement. For example, creating or deleting a + branch, commit, or tag. For Git activity over SSH and HTTPS, users must + have at least one active session signed-in through SSO before they can push to or + pull from a GitLab repository. + +When SSO for web activity is enforced, non-SSO group members do not lose access +immediately. If the user: + +- Has an active session, they can continue accessing the group for up to 24 + hours until the identity provider session times out. +- Is signed out, they cannot access the group after being removed from the + identity provider. + +## Related topics -- Setting up SAML on self-managed GitLab instances, see - [SAML SSO for self-managed GitLab instances](../../../integration/saml.md). -- Commonly-used terms, see the - [glossary of common terms](../../../integration/saml.md#glossary-of-common-terms). -- The differences between SaaS and self-managed authentication and authorization, - see the [SaaS vs. Self-Managed comparison](../../../administration/auth/index.md#saas-vs-self-managed-comparison). +- [SAML SSO for self-managed GitLab instances](../../../integration/saml.md) +- [Glossary of common terms](../../../integration/saml.md#glossary-of-common-terms) +- [Authentication comparison between SaaS and self-managed](../../../administration/auth/index.md#saas-vs-self-managed-comparison) +- [Passwords for users created through integrated authentication](../../../security/passwords_for_integrated_authentication_methods.md) ## Troubleshooting diff --git a/doc/user/infrastructure/iac/terraform_state.md b/doc/user/infrastructure/iac/terraform_state.md index 3935bfd9a86..87404699ad7 100644 --- a/doc/user/infrastructure/iac/terraform_state.md +++ b/doc/user/infrastructure/iac/terraform_state.md @@ -338,6 +338,5 @@ You can also use [the GraphQL API](../../../api/graphql/reference/index.md#mutat ## Related topics -- [Troubleshooting GitLab-managed Terraform state](troubleshooting.md). -- To use GitLab and Terraform to deploy an AWS EC2 instance in a custom VPC, - see [this sample project](https://gitlab.com/gitlab-org/configure/examples/gitlab-terraform-aws). +- [Troubleshooting GitLab-managed Terraform state](troubleshooting.md) +- [Sample project: Terraform deployment of AWS EC2 instance in a custom VPC](https://gitlab.com/gitlab-org/configure/examples/gitlab-terraform-aws) diff --git a/doc/user/packages/yarn_repository/index.md b/doc/user/packages/yarn_repository/index.md index e756a912928..c8f4985a518 100644 --- a/doc/user/packages/yarn_repository/index.md +++ b/doc/user/packages/yarn_repository/index.md @@ -302,10 +302,8 @@ Then you can use `yarn add` to install your packages. ## Related topics -- For full helpful hints information, see the - [npm documentation](../npm_registry/index.md#helpful-hints). -- For Yarn 1 to Yarn 2+ migration information see the - [Yarn Migration Guide](https://yarnpkg.com/getting-started/migration). +- [npm documentation](../npm_registry/index.md#helpful-hints) +- [Yarn Migration Guide](https://yarnpkg.com/getting-started/migration) ## Troubleshooting diff --git a/doc/user/project/changelogs.md b/doc/user/project/changelogs.md index a64edd053b1..8410655c244 100644 --- a/doc/user/project/changelogs.md +++ b/doc/user/project/changelogs.md @@ -313,5 +313,5 @@ an error is produced when generating a changelog. ## Related topics -- [Changelog-related endpoints](../../api/repositories.md) in the Repositories API. -- Developer documentation for [changelog entries](../../development/changelog.md) in GitLab. +- [Changelog-related endpoints](../../api/repositories.md) in the Repositories API +- Developer documentation for [changelog entries](../../development/changelog.md) in GitLab diff --git a/doc/user/project/deploy_keys/index.md b/doc/user/project/deploy_keys/index.md index 92fdc59dde3..6aac0dba63d 100644 --- a/doc/user/project/deploy_keys/index.md +++ b/doc/user/project/deploy_keys/index.md @@ -86,7 +86,6 @@ Prerequisites: 1. Complete the fields. 1. Optional. To grant `read-write` permission, select the **Grant write permissions to this key** checkbox. -1. Optional. Update the **Expiration date**. A project deploy key is enabled when it is created. You can modify only a project deploy key's name and permissions. diff --git a/doc/user/project/import/bitbucket_server.md b/doc/user/project/import/bitbucket_server.md index 9937ea956c4..28ad1f22b8d 100644 --- a/doc/user/project/import/bitbucket_server.md +++ b/doc/user/project/import/bitbucket_server.md @@ -132,5 +132,4 @@ Consider memory constraints on the system before deciding to increase `SIDEKIQ_M ## Related topics -For information on automating user, group, and project import API calls, see -[Automate group and project import](index.md#automate-group-and-project-import). +- [Automate group and project import](index.md#automate-group-and-project-import) diff --git a/doc/user/project/import/gitlab_com.md b/doc/user/project/import/gitlab_com.md index c00709d9697..9cb3ff75d5d 100644 --- a/doc/user/project/import/gitlab_com.md +++ b/doc/user/project/import/gitlab_com.md @@ -33,7 +33,5 @@ When the importer is done, a new GitLab project is created with your imported da ## Related topics -- To automate user, group, and project import API calls, see - [Automate group and project import](index.md#automate-group-and-project-import). -- To import Wiki and merge request data to your new instance, - see [exporting a project](../settings/import_export.md#export-a-project-and-its-data). +- [Automate group and project import](index.md#automate-group-and-project-import) +- [Export a project](../settings/import_export.md#export-a-project-and-its-data) diff --git a/doc/user/project/index.md b/doc/user/project/index.md index da0546b85e6..1512039fb25 100644 --- a/doc/user/project/index.md +++ b/doc/user/project/index.md @@ -179,8 +179,6 @@ Your project's visibility is set to **Private** by default. To change project vi ## Related topics -- For a list of words that you cannot use as project names, see - [reserved project and group names](../../user/reserved_names.md). -- For a list of characters that you cannot use in project and group names, see - [limitations on project and group names](../../user/reserved_names.md#limitations-on-project-and-group-names). -- [Manage projects](working_with_projects.md). +- [Reserved project and group names](../../user/reserved_names.md) +- [Limitations on project and group names](../../user/reserved_names.md#limitations-on-project-and-group-names) +- [Manage projects](working_with_projects.md) diff --git a/doc/user/project/integrations/microsoft_teams.md b/doc/user/project/integrations/microsoft_teams.md index fc5d4d3cc80..fc448382cb4 100644 --- a/doc/user/project/integrations/microsoft_teams.md +++ b/doc/user/project/integrations/microsoft_teams.md @@ -58,4 +58,4 @@ GitLab to send the notifications: ## Related topics -- [Setting up an incoming webhook on Microsoft Teams](https://learn.microsoft.com/en-us/microsoftteams/platform/webhooks-and-connectors/how-to/connectors-using#setting-up-a-custom-incoming-webhook). +- [Setting up an incoming webhook on Microsoft Teams](https://learn.microsoft.com/en-us/microsoftteams/platform/webhooks-and-connectors/how-to/connectors-using#setting-up-a-custom-incoming-webhook) diff --git a/doc/user/project/merge_requests/approvals/settings.md b/doc/user/project/merge_requests/approvals/settings.md index 1ab564c108b..2a11236f9f0 100644 --- a/doc/user/project/merge_requests/approvals/settings.md +++ b/doc/user/project/merge_requests/approvals/settings.md @@ -140,7 +140,7 @@ However, approvals are reset if the target branch is changed. > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/90578) in GitLab 15.3. -If you only want to remove approvals by Code Owners whose files have been changed: +If you only want to remove approvals by Code Owners whose files have been changed when a commit is added: Prerequisite: diff --git a/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md b/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md index f0359446b06..102a2ad1c14 100644 --- a/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md +++ b/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md @@ -147,3 +147,11 @@ merge-request-pipeline-job: Instead, use branch (`push`) pipelines or merge request pipelines, when possible. For details on avoiding two pipelines for a single merge request, read the [`rules` documentation](../../../ci/jobs/job_control.md#avoid-duplicate-pipelines). + +### Merged results pipeline allows merge, despite a failed branch pipeline + +When [the **Pipelines must succeed** setting](#require-a-successful-pipeline-for-merge) +is combined with +[the **Merged results pipelines** feature](../../../ci/pipelines/merged_results_pipelines.md), +failed branch pipeline may be ignored. +[Issue 385841](https://gitlab.com/gitlab-org/gitlab/-/issues/385841) is open to track this. diff --git a/doc/user/project/system_notes.md b/doc/user/project/system_notes.md index 55c02228dde..236f649460b 100644 --- a/doc/user/project/system_notes.md +++ b/doc/user/project/system_notes.md @@ -53,4 +53,4 @@ The filtering options are: ## Related topics -- The [Notes API](../../api/notes.md) can add system notes to objects in GitLab. +- [Notes API](../../api/notes.md) diff --git a/doc/user/public_access.md b/doc/user/public_access.md index 87380ec324e..58eebc16d74 100644 --- a/doc/user/public_access.md +++ b/doc/user/public_access.md @@ -95,8 +95,7 @@ For more information, see [Restrict visibility levels](admin_area/settings/visib ## Related topics -- For more granular control of project features, you can - [change the visibility of features](project/working_with_projects.md#change-the-visibility-of-individual-features-in-a-project). +- [Change the visibility of features](project/working_with_projects.md#change-the-visibility-of-individual-features-in-a-project) <!-- ## Troubleshooting diff --git a/doc/user/report_abuse.md b/doc/user/report_abuse.md index a20a699e550..de2b82c28d3 100644 --- a/doc/user/report_abuse.md +++ b/doc/user/report_abuse.md @@ -66,5 +66,4 @@ A URL to the reported user's comment is pre-filled in the abuse report's ## Related topics -- Administrators can view and resolve abuse reports. - For more information, see [abuse reports administration documentation](admin_area/review_abuse_reports.md). +- [Abuse reports administration documentation](admin_area/review_abuse_reports.md) |