Merge branch 'selhorn-menu-updates-9' into 'master'

Updated Menu to Main menu

See merge request !97879

doc/raketasks/backup_restore.md

@@ -318,7 +318,7 @@ To prepare the new server:
       ```
 
 1. Disable periodic background jobs:
-   1. On the top bar, select **Menu > Admin**.
+   1. On the top bar, select **Main menu > Admin**.
    1. On the left sidebar, select **Monitoring > Background Jobs**.
    1. Under the Sidekiq dashboard, select **Cron** tab and then
       **Disable All**.
@@ -398,7 +398,7 @@ To prepare the new server:
 
 1. [Restore the GitLab backup](#restore-gitlab).
 1. Verify that the Redis database restored correctly:
-   1. On the top bar, select **Menu > Admin**.
+   1. On the top bar, select **Main menu > Admin**.
    1. On the left sidebar, select **Monitoring > Background Jobs**.
    1. Under the Sidekiq dashboard, verify that the numbers
       match with what was shown on the old server.

doc/security/password_length_limits.md

@@ -30,7 +30,7 @@ The user password length is set to a minimum of 8 characters by default.
 
 To change the minimum password length using GitLab UI:
 
-1. On the top bar, select **Menu > Admin**.
+1. On the top bar, select **Main menu > Admin**.
 1. On the left sidebar, select **Settings > General** and expand **Sign-up restrictions**.
 
    ![Minimum password length settings](../user/admin_area/img/minimum_password_length_settings_v12_6.png)

doc/security/ssh_keys_restrictions.md

@@ -20,7 +20,7 @@ limit the allowed SSH key algorithms.
 GitLab allows you to restrict the allowed SSH key technology as well as specify
 the minimum key length for each technology:
 
-1. On the top bar, select **Menu > Admin**.
+1. On the top bar, select **Main menu > Admin**.
 1. On the left sidebar, select **Settings > General** (`/admin/application_settings/general`).
 1. Expand the **Visibility and access controls** section:
 

doc/security/two_factor_authentication.md

@@ -26,7 +26,7 @@ cannot leave the 2FA configuration area at `/-/profile/two_factor_auth`.
 
 To enable 2FA for all users:
 
-1. On the top bar, select **Menu > Admin**.
+1. On the top bar, select **Main menu > Admin**.
 1. On the left sidebar, select **Settings > General** (`/admin/application_settings/general`).
 1. Expand the **Sign-in restrictions** section, where you can configure both.
 
@@ -52,7 +52,7 @@ Prerequisites:
 
 To enforce 2FA only for certain groups:
 
-1. On the top bar, select **Menu > Groups** and find your group.
+1. On the top bar, select **Main menu > Groups** and find your group.
 1. On the left sidebar, select **Settings > General**.
 1. Expand **Permissions and group features**.
 1. Select **All users in this group must set up two-factor authentication**.

doc/security/unlock_user.md

@@ -14,7 +14,7 @@ Users are locked after ten failed sign-in attempts. These users remain locked:
 
 ## Unlock a user from the Admin Area
 
-1. On the top bar, select **Menu > Admin**.
+1. On the top bar, select **Main menu > Admin**.
 1. On the left sidebar, select **Overview > Users**.
 1. Use the search bar to find the locked user.
 1. From the **User administration** dropdown select **Unlock**.

doc/security/user_email_confirmation.md

@@ -11,7 +11,7 @@ GitLab can be configured to require confirmation of a user's email address when
 the user signs up. When this setting is enabled, the user is unable to sign in until
 they confirm their email address.
 
-1. On the top bar, select **Menu > Admin**.
+1. On the top bar, select **Main menu > Admin**.
 1. On the left sidebar, select **Settings > General** (`/admin/application_settings/general`).
 1. Expand the **Sign-up restrictions** section and look for the **Send confirmation email on sign-up** option.
 

doc/security/user_file_uploads.md

@@ -39,7 +39,7 @@ Prerequisite:
 
 To configure authentication settings for all media files:
 
-1. On the top bar, select **Menu > Projects** and find your project.
+1. On the top bar, select **Main menu > Projects** and find your project.
 1. On the left sidebar, select **Settings > General**.
 1. Expand **Visibility, project features, permissions**.
 1. Scroll to **Project visibility** and select **Require authentication to view media files**.

doc/security/webhooks.md

@@ -42,7 +42,7 @@ To prevent exploitation of insecure internal web services, all webhook requests
 
 To allow access to these addresses:
 
-1. On the top bar, select **Menu > Admin**.
+1. On the top bar, select **Main menu > Admin**.
 1. On the left sidebar, select **Settings > Network**.
 1. Expand **Outbound requests**.
 1. Select the **Allow requests to the local network from web hooks and services** checkbox.
@@ -52,7 +52,7 @@ To allow access to these addresses:
 [System hooks](../administration/system_hooks.md) are permitted to make requests to local network by default because
 they are set up by administrators. To prevent system hook requests to the local network:
 
-1. On the top bar, select **Menu > Admin**.
+1. On the top bar, select **Main menu > Admin**.
 1. On the left sidebar, select **Settings > Network**.
 1. Expand **Outbound requests**.
 1. Clear the **Allow requests to the local network from system hooks** checkbox.
@@ -64,7 +64,7 @@ they are set up by administrators. To prevent system hook requests to the local
 You can allow certain domains and IP addresses to be accessible to both system hooks and webhooks, even when local
 requests are forbidden. To add these domains to the allowlist:
 
-1. On the top bar, select **Menu > Admin**.
+1. On the top bar, select **Main menu > Admin**.
 1. On the left sidebar, select **Settings > Network**.
 1. Expand **Outbound requests** and add entries.