From 21a3562717979fe189a0ccfcbca9dec0432d374d Mon Sep 17 00:00:00 2001
From: Suzanne Selhorn <sselhorn@gitlab.com>
Date: Tue, 18 Jul 2023 14:02:43 -0700
Subject: [PATCH] Changed user/admin to admin path
Related to: https://gitlab.com/gitlab-org/gitlab/-/issues/384335
---
doc/development/application_limits.md | 2 +-
.../cicd/cicd_reference_documentation_guide.md | 2 +-
.../site_architecture/folder_structure.md | 13 ++++---------
doc/development/geo.md | 4 ++--
doc/install/aws/manual_install_aws.md | 6 +++---
doc/integration/omniauth.md | 2 +-
.../hardening_application_recommendations.md | 8 ++++----
doc/security/index.md | 2 +-
8 files changed, 17 insertions(+), 22 deletions(-)
diff --git a/doc/development/application_limits.md b/doc/development/application_limits.md
index b1efc11db6274..40d157a4411a3 100644
--- a/doc/development/application_limits.md
+++ b/doc/development/application_limits.md
@@ -171,7 +171,7 @@ The process for adding a new throttle is loosely:
1. Extend `Gitlab::RackAttack` and `Gitlab::RackAttack::Request` to configure the new rate limit,
and apply it to the desired requests.
1. Add the new settings to the Admin Area form in `app/views/admin/application_settings/_ip_limits.html.haml`.
-1. Document the new settings in [User and IP rate limits](../user/admin_area/settings/user_and_ip_rate_limits.md) and [Application settings API](../api/settings.md).
+1. Document the new settings in [User and IP rate limits](../administration/settings/user_and_ip_rate_limits.md) and [Application settings API](../api/settings.md).
1. Configure the rate limit for GitLab.com and document it in [GitLab.com-specific rate limits](../user/gitlab_com/index.md#gitlabcom-specific-rate-limits).
Refer to these past issues for implementation details:
diff --git a/doc/development/cicd/cicd_reference_documentation_guide.md b/doc/development/cicd/cicd_reference_documentation_guide.md
index 530bc62b60320..e358b24c60f35 100644
--- a/doc/development/cicd/cicd_reference_documentation_guide.md
+++ b/doc/development/cicd/cicd_reference_documentation_guide.md
@@ -125,7 +125,7 @@ can include changes introduced in different GitLab versions. For example:
**Additional details**:
- The expiration time period begins when the artifact is uploaded and stored on GitLab.
- If the expiry time is not defined, it defaults to the [instance wide setting](../../user/admin_area/settings/continuous_integration.md#default-artifacts-expiration).
+ If the expiry time is not defined, it defaults to the [instance wide setting](../../administration/settings/continuous_integration.md#default-artifacts-expiration).
- To override the expiration date and protect artifacts from being automatically deleted:
- Select **Keep** on the job page.
- [In GitLab 13.3 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/22761), set the value of
diff --git a/doc/development/documentation/site_architecture/folder_structure.md b/doc/development/documentation/site_architecture/folder_structure.md
index f59e24c19c5c9..1c9fc1441c47e 100644
--- a/doc/development/documentation/site_architecture/folder_structure.md
+++ b/doc/development/documentation/site_architecture/folder_structure.md
@@ -26,7 +26,7 @@ Put files for a specific product area into the related folder:
| Directory | Contents |
|:----------------------|:------------------|
| `doc/user/` | Documentation for users. Anything that can be done in the GitLab user interface goes here, including usage of the `/admin` interface. |
-| `doc/administration/` | Documentation that requires the user to have access to the server where GitLab is installed. Administrator settings in the GitLab user interface are under `doc/user/admin_area/`. |
+| `doc/administration/` | Documentation that requires the user to have access to the server where GitLab is installed. Administrator settings in the GitLab user interface are under `doc/administration/`. |
| `doc/api/` | Documentation for the API. |
| `doc/development/` | Documentation related to the development of GitLab, whether contributing code or documentation. Related process and style guides should go here. |
| `doc/legal/` | Legal documents about contributing to GitLab. |
@@ -61,14 +61,9 @@ When working with directories and files:
- `doc/user/profile/` should contain all profile related documentation.
Every page you would navigate under `/profile` should have its own document,
for example, `account.md`, `applications.md`, or `emails.md`.
- - `doc/user/admin_area/` should contain all administrator-related
- documentation describing what can be achieved by accessing the GitLab
- administrator interface (not to be confused with `doc/administration` where
- server access is required).
- - Every category under `/admin/application_settings/` should have its
- own document located at `doc/user/admin_area/settings/`. For example,
- the **Visibility and Access Controls** category should have a document
- located at `doc/user/admin_area/settings/visibility_and_access_controls.md`.
+1. In the `doc/administration/` directory: all administrator-related
+ documentation for administrators, including admin tasks done in both
+ the UI and on the backend servers.
If you're unsure where to place a document or a content addition, this shouldn't
stop you from authoring and contributing. Use your best judgment, and then ask
diff --git a/doc/development/geo.md b/doc/development/geo.md
index a53e7fa0a9659..a39f97f12416b 100644
--- a/doc/development/geo.md
+++ b/doc/development/geo.md
@@ -111,7 +111,7 @@ projects that need updating. Those projects can be:
timestamp that is more recent than the `last_repository_successful_sync_at`
timestamp in the `Geo::ProjectRegistry` model.
- Manual: The administrator can manually flag a repository to resync in the
- [Geo Admin Area](../user/admin_area/geo_sites.md).
+ [Geo Admin Area](../administration/geo_sites.md).
When we fail to fetch a repository on the secondary `RETRIES_BEFORE_REDOWNLOAD`
times, Geo does a so-called _re-download_. It will do a clean clone
@@ -466,7 +466,7 @@ basically hashes all Git refs together and stores that hash in the
The **secondary** site does the same to calculate the hash of its
clone, and compares the hash with the value the **primary** site
calculated. If there is a mismatch, Geo will mark this as a mismatch
-and the administrator can see this in the [Geo Admin Area](../user/admin_area/geo_sites.md).
+and the administrator can see this in the [Geo Admin Area](../administration/geo_sites.md).
## Geo proxying
diff --git a/doc/install/aws/manual_install_aws.md b/doc/install/aws/manual_install_aws.md
index 01d79e67d53c2..92ef08c2447d9 100644
--- a/doc/install/aws/manual_install_aws.md
+++ b/doc/install/aws/manual_install_aws.md
@@ -268,7 +268,7 @@ On the EC2 dashboard, look for Load Balancer in the left navigation bar:
1. Select **Configure Health Check** and set up a health check for your EC2 instances.
1. For **Ping Protocol**, select HTTP.
1. For **Ping Port**, enter 80.
- 1. For **Ping Path** - we recommend that you [use the Readiness check endpoint](../../administration/load_balancer.md#readiness-check). You must add [the VPC IP Address Range (CIDR)](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-groups.html#elb-vpc-nacl) to the [IP allowlist](../../administration/monitoring/ip_allowlist.md) for the [Health Check endpoints](../../user/admin_area/monitoring/health_check.md)
+ 1. For **Ping Path** - we recommend that you [use the Readiness check endpoint](../../administration/load_balancer.md#readiness-check). You must add [the VPC IP Address Range (CIDR)](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-groups.html#elb-vpc-nacl) to the [IP allowlist](../../administration/monitoring/ip_allowlist.md) for the [Health Check endpoints](../../administration/monitoring/health_check.md)
1. Keep the default **Advanced Details** or adjust them according to your needs.
1. Select **Add EC2 Instances** - don't add anything as we create an Auto Scaling Group later to manage instances for us.
1. Select **Add Tags** and add any tags you need.
@@ -741,7 +741,7 @@ GitLab provides its own integrated monitoring solution based on Prometheus.
For more information about how to set it up, see
[GitLab Prometheus](../../administration/monitoring/prometheus/index.md).
-GitLab also has various [health check endpoints](../../user/admin_area/monitoring/health_check.md)
+GitLab also has various [health check endpoints](../../administration/monitoring/health_check.md)
that you can ping and get reports.
## GitLab Runner
@@ -833,7 +833,7 @@ to request additional material:
Geo is the solution for widely distributed development teams.
- [Linux package](https://docs.gitlab.com/omnibus/) - Everything you must know
about administering your GitLab instance.
-- [Add a license](../../user/admin_area/license.md):
+- [Add a license](../../administration/license.md):
Activate all GitLab Enterprise Edition functionality with a license.
- [Pricing](https://about.gitlab.com/pricing/): Pricing for the different tiers.
diff --git a/doc/integration/omniauth.md b/doc/integration/omniauth.md
index 0389b91fc7004..01ea640846968 100644
--- a/doc/integration/omniauth.md
+++ b/doc/integration/omniauth.md
@@ -309,7 +309,7 @@ To enable automatic linking for SAML, see the [SAML setup instructions](saml.md#
## Create an external providers list
You can define a list of external OmniAuth providers.
-Users who create accounts or sign in to GitLab through the listed providers do not get access to [internal projects](../user/public_access.md#internal-projects-and-groups) and are marked as [external users](../user/admin_area/external_users.md).
+Users who create accounts or sign in to GitLab through the listed providers do not get access to [internal projects](../user/public_access.md#internal-projects-and-groups) and are marked as [external users](../administration/external_users.md).
To define the external providers list, use the full name of the provider,
for example, `google_oauth2` for Google. For provider names, see the
diff --git a/doc/security/hardening_application_recommendations.md b/doc/security/hardening_application_recommendations.md
index 9d4d2d562fd91..e9c09abdea117 100644
--- a/doc/security/hardening_application_recommendations.md
+++ b/doc/security/hardening_application_recommendations.md
@@ -121,7 +121,7 @@ select the **Disabled feed token** checkbox.
If all of your users are coming from specific IP addresses, use **Global-allowed IP ranges**
to specifically allow only those addresses.
-For more details on **Visibility and access control**, see [visibility and access controls](../user/admin_area/settings/visibility_and_access_controls.md).
+For more details on **Visibility and access control**, see [visibility and access controls](../administration/settings/visibility_and_access_controls.md).
For information on SSH settings, see
[SSH keys restrictions](../security/ssh_keys_restrictions.md).
@@ -134,7 +134,7 @@ restricted. Account avatars can be manually uploaded by users.
The settings in this section are intended to help enforce a custom implementation
of your own specific standards on your users. As the various scenarios are too many
and too varied, you should review the
-[account and limit settings documentation](../user/admin_area/settings/account_and_limit_settings.md)
+[account and limit settings documentation](../administration/settings/account_and_limit_settings.md)
and apply changes to enforce your own policies.
### Sign-up restrictions
@@ -158,7 +158,7 @@ email addresses, then list that domain in **Allowed domains for sign-ups**. This
prevents those with email addresses in other domains from signing up.
For more detailed information, see
-[sign-up restrictions](../user/admin_area/settings/sign_up_restrictions.md).
+[sign-up restrictions](../administration/settings/sign_up_restrictions.md).
### Sign-in restrictions
@@ -176,7 +176,7 @@ In **Email notification for unknown sign-ins**, ensure that **Enable email notif
is selected. This sends an email to users when a sign-in occurs from an unrecognized location.
For more detailed information, see
-[sign-in restrictions](../user/admin_area/settings/sign_in_restrictions.md).
+[sign-in restrictions](../administration/settings/sign_in_restrictions.md).
## Integrations
diff --git a/doc/security/index.md b/doc/security/index.md
index a62d717111203..1b486ab5feb44 100644
--- a/doc/security/index.md
+++ b/doc/security/index.md
@@ -27,6 +27,6 @@ type: index
- [Project Import decompressed archive size limits](project_import_decompressed_archive_size_limits.md)
- [Responding to security incidents](responding_to_security_incidents.md)
-To harden your GitLab instance and minimize the risk of unwanted user account creation, consider access control features like [Sign up restrictions](../user/admin_area/settings/sign_up_restrictions.md) and [Authentication options](../topics/authentication/index.md). For more detailed information, refer to [Hardening](hardening.md).
+To harden your GitLab instance and minimize the risk of unwanted user account creation, consider access control features like [Sign up restrictions](../administration/settings/sign_up_restrictions.md) and [Authentication options](../topics/authentication/index.md). For more detailed information, refer to [Hardening](hardening.md).
Self-managed GitLab customers and administrators are responsible for the security of their underlying hosts, and for keeping GitLab itself up to date. It is important to [regularly patch GitLab](../policy/maintenance.md), patch your operating system and its software, and harden your hosts in accordance with vendor guidance.
--
GitLab