Update Access and Compliance documentation for new Menu structure

doc/administration/audit_events.md

@@ -6,7 +6,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Audit Events **(PREMIUM)**
 
-GitLab offers a way to view the changes made within the GitLab server for owners and administrators on a [paid plan](https://about.gitlab.com/pricing/).
+GitLab offers a way to view the changes made within the GitLab server for owners and administrators
+on a [paid plan](https://about.gitlab.com/pricing/).
 
 GitLab system administrators can also take advantage of the logs located on the
 file system. See [the logs system documentation](logs.md#audit_jsonlog) for more details.
@@ -56,7 +57,11 @@ A user with:
 
 Group events do not include project audit events.
 
-To view a group's audit events, navigate to **Group > Security & Compliance > Audit Events**.
+To view a group's audit events:
+
+1. Go to the group.
+1. On the left sidebar, select **Security & Compliance > Audit Events**.
+
 From there, you can see the following actions:
 
 - Group name or path changed.
@@ -86,7 +91,11 @@ Group events can also be accessed via the [Group Audit Events API](../api/audit_
 A user with a Maintainer role (or above) can retrieve project audit events of all users.
 A user with a Developer role is limited to project audit events based on their individual actions.
 
-To view a project's audit events, navigate to **Project > Security & Compliance > Audit Events**.
+To view a project's audit events:
+
+1. Go to the project.
+1. On the left sidebar, select **Security & Compliance > Audit Events**.
+
 From there, you can see the following actions:
 
 - Added or removed deploy keys
@@ -126,7 +135,10 @@ changed what and when for audit purposes.
 
 Instance events do not include group or project audit events.
 
-To view the server-wide administrator log, visit **Admin Area > Monitoring > Audit Events**.
+To view the server-wide audit events:
+
+1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the left sidebar, select **Monitoring > Audit Events**.
 
 The following user actions are recorded:
 
@@ -187,7 +199,7 @@ It may make the user interface for your project or audit events very busy, and t
 `audit_events` PostgreSQL table may increase considerably. It's disabled by default
 to prevent performance degradations on GitLab instances with very high Git write traffic.
 
-In an upcoming release, Audit Events for Git push events will be enabled
+In an upcoming release, Audit Events for Git push events are planned to be enabled
 by default. Follow our [Partitioning strategy for Audit Events epic](https://gitlab.com/groups/gitlab-org/-/epics/3206) for updates.
 
 If you still wish to enable **Repository push** events in your instance, follow
@@ -229,11 +241,12 @@ Export to CSV allows customers to export the current filter view of your audit e
 CSV file, which stores tabular data in plain text. The data provides a comprehensive view with respect to
 audit events.
 
-To export the Audit Events to CSV, navigate to
-**{monitor}** **Admin Area > Monitoring > Audit Events**
+To export the Audit Events to CSV:
 
+1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the left sidebar, select **Monitoring > Audit Events**.
 1. Select the available search [filters](#search).
-1. Click **Export as CSV**.
+1. Select **Export as CSV**.
 
 ### Sort
 

doc/administration/auth/ldap/index.md

@@ -367,7 +367,7 @@ Instead of having the LDAP integration credentials stored in plaintext in the co
 use an encrypted file for the LDAP credentials. To use this feature, you first need to enable
 [GitLab encrypted configuration](../../encrypted_configuration.md).
 
-The encrypted configuration for LDAP exists in an encrypted YAML file. By default the file will be created at
+The encrypted configuration for LDAP exists in an encrypted YAML file. By default the file is created at
 `shared/encrypted_configuration/ldap.yaml.enc`. This location is configurable in the GitLab configuration.
 
 The unencrypted contents of the file should be a subset of the secret settings from your `servers` block in the LDAP
@@ -646,7 +646,7 @@ For information on adding group links by using CNs and filters, refer to the
 
 As an extension of group sync, you can automatically manage your global GitLab
 administrators. Specify a group CN for `admin_group` and all members of the
-LDAP group will be given administrator privileges. The configuration looks
+LDAP group are given administrator privileges. The configuration looks
 like the following.
 
 NOTE:
@@ -704,7 +704,9 @@ When enabled, the following applies:
 To enable it you need to:
 
 1. [Enable LDAP](#configuration)
-1. Go to the Admin Area (**{admin}**) and select **Settings > Visibility and access controls**.
+1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the left sidebar, select **Settings > General**.
+1. Expand the **Visibility and access controls** section.
 1. Ensure the **Lock memberships to LDAP synchronization** checkbox is selected.
 
 ### Adjusting LDAP group sync schedule **(PREMIUM SELF)**
@@ -748,7 +750,7 @@ sync to run once every two hours at the top of the hour.
 
 ### External groups **(PREMIUM SELF)**
 
-Using the `external_groups` setting will allow you to mark all users belonging
+Using the `external_groups` setting allows you to mark all users belonging
 to these groups as [external users](../../../user/permissions.md#external-users).
 Group membership is checked periodically through the `LdapGroupSync` background
 task.

doc/administration/auth/ldap/ldap-troubleshooting.md

@@ -20,7 +20,7 @@ or `encryption: 'simple_tls'` and `port: 636`.
 
 #### Connection times out
 
-If GitLab cannot reach your LDAP endpoint, you will see a message like this:
+If GitLab cannot reach your LDAP endpoint, you see a message like this:
 
 ```plaintext
 Could not authenticate you from Ldapmain because "Connection timed out - user specified timeout".
@@ -145,7 +145,8 @@ may see the following message: `Access denied for your LDAP account`.
 
 We have a workaround, based on toggling the access level of affected users:
 
-1. As an administrator, go to **Admin Area > Overview > Users**.
+1. As an administrator, on the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the left sidebar, select **Overview > Users**.
 1. Select the name of the affected user.
 1. In the user's administrative page, press **Edit** on the top right of the page.
 1. Change the user's access level from `Regular` to `Admin` (or vice versa),
@@ -202,9 +203,11 @@ field contains no data:
 
 To resolve this:
 
-1. Go to both of the following in the Admin Area (**{admin}**):
-    - **Settings > General > Account and limit**
-    - **Settings > General > Sign-up restrictions**.
+1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the left sidebar, go to **Settings > General**.
+1. Expand both of the following:
+   - **Account and limit**.
+   - **Sign-up restrictions**.
 1. Check, for example, the **Default projects limit** or **Allowed domains for sign-ups**
    fields and ensure that a relevant value is configured.
 
@@ -345,8 +348,9 @@ things to check to debug the situation.
   group](index.md#adding-group-links).
 - Check that the user has an LDAP identity:
   1. Sign in to GitLab as an administrator user.
-  1. Go to **Admin area > Users**.
-  1. Search for the user
+  1. On the top bar, select **Menu >** **{admin}** **Admin**.
+  1. On the left sidebar, select **Overview > Users**.
+  1. Search for the user.
   1. Open the user by clicking their name. Do not click **Edit**.
   1. Select the **Identities** tab. There should be an LDAP identity with
      an LDAP DN as the 'Identifier'. If not, this user hasn't signed in with
@@ -383,7 +387,7 @@ the following are true:
 - The configured `admin_group` in the `gitlab.rb` is a CN, rather than a DN or an array.
 - This CN falls under the scope of the configured `group_base`.
 - The members of the `admin_group` have already signed into GitLab with their LDAP
-  credentials. GitLab will only grant this administrator access to the users whose
+  credentials. GitLab only grants this administrator access to the users whose
   accounts are already connected to LDAP.
 
 If all the above are true and the users are still not getting access, [run a manual
@@ -412,7 +416,7 @@ output](#example-console-output-after-a-group-sync).
 ##### Example console output after a group sync **(PREMIUM SELF)**
 
 Like the output from the user sync, the output from the [manual group
-sync](#sync-all-groups) will also be very verbose. However, it contains lots
+sync](#sync-all-groups) is also very verbose. However, it contains lots
 of helpful information.
 
 Indicates the point where syncing actually begins:
@@ -423,7 +427,7 @@ Started syncing 'ldapmain' provider for 'my_group' group
 
 The following entry shows an array of all user DNs GitLab sees in the LDAP server.
 Note that these are the users for a single LDAP group, not a GitLab group. If
-you have multiple LDAP groups linked to this GitLab group, you will see multiple
+you have multiple LDAP groups linked to this GitLab group, you see multiple
 log entries like this - one for each LDAP group. If you don't see an LDAP user
 DN in this log entry, LDAP is not returning the user when we do the lookup.
 Verify the user is actually in the LDAP group.
@@ -437,7 +441,7 @@ Members in 'ldap_group_1' LDAP group: ["uid=john0,ou=people,dc=example,dc=com",
 "uid=mary4,ou=people,dc=example,dc=com"]
 ```
 
-Shortly after each of the above entries, you will see a hash of resolved member
+Shortly after each of the above entries, you see a hash of resolved member
 access levels. This hash represents all user DNs GitLab thinks should have
 access to this group, and at which access level (role). This hash is additive,
 and more DNs may be added, or existing entries modified, based on additional
@@ -478,21 +482,21 @@ Finally, the following entry says syncing has finished for this group:
 Finished syncing all providers for 'my_group' group
 ```
 
-Once all the configured group links have been synchronized, GitLab will look
+Once all the configured group links have been synchronized, GitLab looks
 for any Administrators or External users to sync:
 
 ```shell
 Syncing admin users for 'ldapmain' provider
 ```
 
-The output will look similar to what happens with a single group, and then
-this line will indicate the sync is finished:
+The output looks similar to what happens with a single group, and then
+this line indicates the sync is finished:
 
 ```shell
 Finished syncing admin users for 'ldapmain' provider
 ```
 
-If [administrator sync](index.md#administrator-sync) is not configured, you'll see a message
+If [administrator sync](index.md#administrator-sync) is not configured, you see a message
 stating as such:
 
 ```shell
@@ -518,8 +522,8 @@ group = Group.find_by(name: 'my_gitlab_group')
 EE::Gitlab::Auth::Ldap::Sync::Group.execute_all_providers(group)
 ```
 
-The output will be similar to
-[that you'd get from syncing all groups](#example-console-output-after-a-group-sync).
+The output is similar to
+[that you get from syncing all groups](#example-console-output-after-a-group-sync).
 
 #### Query a group in LDAP **(PREMIUM SELF)**
 
@@ -540,24 +544,25 @@ ldap_group.member_uids
 
 When an LDAP user is created in GitLab, their LDAP DN is stored for later reference.
 
-If GitLab cannot find a user by their DN, it will fall back
-to finding the user by their email. If the lookup is successful, GitLab will
-update the stored DN to the new value so both values will now match what's in
+If GitLab cannot find a user by their DN, it falls back
+to finding the user by their email. If the lookup is successful, GitLab
+updates the stored DN to the new value so both values now match what's in
 LDAP.
 
-If the email has changed and the DN has not, GitLab will find the user with
+If the email has changed and the DN has not, GitLab finds the user with
 the DN and update its own record of the user's email to match the one in LDAP.
 
-However, if the primary email _and_ the DN change in LDAP, then GitLab will
-have no way of identifying the correct LDAP record of the user and, as a
-result, the user will be blocked. To rectify this, the user's existing
-profile will have to be updated with at least one of the new values (primary
+However, if the primary email _and_ the DN change in LDAP, then GitLab 
+has no way of identifying the correct LDAP record of the user and, as a
+result, the user is blocked. To rectify this, the user's existing
+profile must be updated with at least one of the new values (primary
 email or DN) so the LDAP record can be found.
 
-The following script will update the emails for all provided users so they
-won't be blocked or unable to access their accounts.
+The following script updates the emails for all provided users so they
+aren't blocked or unable to access their accounts.
 
->**NOTE**: The following script will require that any new accounts with the new
+NOTE:
+The following script requires that any new accounts with the new
 email address are removed first. This is because emails have to be unique in GitLab.
 
 Go to the [rails console](#rails-console) and then run:
@@ -604,23 +609,23 @@ users, [see what to do when no users are found](#no-users-are-found).
 ### GitLab logs
 
 If a user account is blocked or unblocked due to the LDAP configuration, a
-message will be [logged to `application.log`](../../logs.md#applicationlog).
+message is [logged to `application.log`](../../logs.md#applicationlog).
 
 If there is an unexpected error during an LDAP lookup (configuration error,
-timeout), the sign-in is rejected and a message will be [logged to
+timeout), the sign-in is rejected and a message is [logged to
 `production.log`](../../logs.md#productionlog).
 
 ### ldapsearch
 
-`ldapsearch` is a utility that will allow you to query your LDAP server. You can
+`ldapsearch` is a utility that allows you to query your LDAP server. You can
 use it to test your LDAP settings and ensure that the settings you're using
-will get you the results you expect.
+get you the results you expect.
 
 When using `ldapsearch`, be sure to use the same settings you've already
 specified in your `gitlab.rb` configuration so you can confirm what happens
 when those exact settings are used.
 
-Running this command on the GitLab host will also help confirm that there's no
+Running this command on the GitLab host also helps confirm that there's no
 obstruction between the GitLab host and LDAP.
 
 For example, consider the following GitLab configuration:
@@ -701,9 +706,9 @@ For instructions about how to use the rails console, refer to this
 
 #### Enable debug output
 
-This will provide debug output that will be useful to see
-what GitLab is doing and with what. This value is not persisted, and will only
-be enabled for this session in the rails console.
+This provides debug output that is useful to see
+what GitLab is doing and with what. This value is not persisted, and is only
+enabled for this session in the rails console.
 
 To enable debug output in the rails console, [enter the rails
 console](#rails-console) and run:

doc/integration/kerberos.md

@@ -25,7 +25,7 @@ mythology; Kerberos was a three-headed dog who guarded the gates of Hades.
 
 For GitLab to offer Kerberos token-based authentication, perform the
 following prerequisites. You still need to configure your system for
-Kerberos usage, such as specifying realms. GitLab will make use of the
+Kerberos usage, such as specifying realms. GitLab makes use of the
 system's Kerberos settings.
 
 ### GitLab keytab
@@ -34,7 +34,7 @@ system's Kerberos settings.
    If your GitLab server is `gitlab.example.com` and your Kerberos realm
    `EXAMPLE.COM`, create a Service Principal `HTTP/gitlab.example.com@EXAMPLE.COM`
    in your Kerberos database.
-1. Create a keytab on the GitLab server for the above Service Principal, e.g.
+1. Create a keytab on the GitLab server for the above Service Principal. For example,
    `/etc/http.keytab`.
 
 The keytab is a sensitive file and must be readable by the GitLab user. Set
@@ -107,8 +107,9 @@ set up GitLab to create a new account when a Kerberos user tries to sign in.
 If you're an administrator, you can link a Kerberos account to an
 existing GitLab account. To do so:
 
-1. Navigate to **Admin Area > Overview > Users > Example User**.
-1. Select the Identities tab.
+1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the left sidebar, select **Overview > Users**.
+1. Select a user, then select the **Identities** tab.
 1. Select 'Kerberos SPNEGO' in the 'Provider' dropdown box.
 1. Make sure the **Identifier** corresponds to the Kerberos username.
 1. Select **Save changes**.
@@ -145,8 +146,9 @@ With that information at hand:
       administrator if you think this is an error.
       ```
 
-      1. As an administrator, you can confirm the new, blocked account.
-         Select **Admin Area > Overview > Users** and review the Blocked tab.
+      1. As an administrator, you can confirm the new, blocked account:
+         1. On the top bar, select **Menu >** **{admin}** **Admin**.
+         1. On the left sidebar, select **Overview > Users** and review the **Blocked** tab.
       1. You can enable the user.
    1. If `block_auto_created_users` is false, the Kerberos user is
       authenticated and is signed in to GitLab.
@@ -181,7 +183,7 @@ LDAP Distinguished Names look like `sAMAccountName=foo,dc=ad,dc=example,dc=com`.
 You can configure custom allowed realms when the user's Kerberos realm doesn't
 match the domain from the user's LDAP DN. The configuration value must specify
 all domains that users may be expected to have. Any other domains are
-ignored and an LDAP identity won't be linked.
+ignored and an LDAP identity is not linked.
 
 **For Omnibus installations**
 
@@ -214,12 +216,12 @@ A linked Kerberos account enables you to `git pull` and `git push` using your
 Kerberos account, as well as your standard GitLab credentials.
 
 GitLab users with a linked Kerberos account can also `git pull` and `git push`
-using Kerberos tokens, i.e., without having to send their password with each
+using Kerberos tokens. That is, without having to send their password with each
 operation.
 
 WARNING:
 There is a [known issue](https://github.com/curl/curl/issues/1261) with `libcurl`
-older than version 7.64.1 wherein it won't reuse connections when negotiating.
+older than version 7.64.1 wherein it doesn't reuse connections when negotiating.
 This leads to authorization issues when push is larger than `http.postBuffer`
 configuration. Ensure that Git is using at least `libcurl` 7.64.1 to avoid this. To
 know the `libcurl` version installed, run `curl-config --version`.
@@ -236,13 +238,13 @@ authentication fails.
 
 For GitLab users to be able to use either `basic` or `negotiate` authentication
 with older Git versions, it is possible to offer Kerberos ticket-based
-authentication on a different port (e.g. 8443) while the standard port offers
-only `basic` authentication.
+authentication on a different port (for example, `8443`) while the standard port
+offers only `basic` authentication.
 
 **For source installations with HTTPS**
 
 1. Edit the NGINX configuration file for GitLab
-   (e.g., `/etc/nginx/sites-available/gitlab-ssl`) and configure NGINX to
+   (for example, `/etc/nginx/sites-available/gitlab-ssl`) and configure NGINX to
    listen to port `8443` in addition to the standard HTTPS port:
 
    ```conf

doc/integration/oauth_provider.md

@@ -27,8 +27,8 @@ of the resource owner or the end-user.
 OAuth 2 can be used:
 
 - To allow users to sign in to your application with their GitLab.com account.
-- To set up GitLab.com for authentication to your GitLab instance.
-(see [GitLab OmniAuth](gitlab.md)).
+- To set up GitLab.com for authentication to your GitLab instance. See
+  [GitLab OmniAuth](gitlab.md).
 
 The 'GitLab Importer' feature also uses OAuth 2 to give access
 to repositories without sharing user credentials to your GitLab.com account.
@@ -63,7 +63,7 @@ To add a new application for your user:
 To add a new application for a group:
 
 1. Navigate to the desired group.
-1. In the left sidebar, select **Settings > Applications**.
+1. On the left sidebar, select **Settings > Applications**.
 1. Enter a **Name**, **Redirect URI** and OAuth 2 scopes as defined in [Authorized Applications](#authorized-applications).
    The **Redirect URI** is the URL where users are sent after they authorize with GitLab.
 1. Select **Save application**. GitLab displays:
@@ -73,10 +73,13 @@ To add a new application for a group:
 
 ## Instance-wide applications
 
-To create an application for your GitLab instance, select
-**Admin Area > Applications > New application**.
+To create an application for your GitLab instance:
 
-When creating an **Admin Area** application, you can mark it as _trusted_.
+1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the left sidebar, select **Applications**.
+1. Select **New application**.
+
+When creating application in the **Admin Area** , you can mark it as _trusted_.
 The user authorization step is automatically skipped for this application.
 
 ## Authorized applications

doc/security/password_length_limits.md

@@ -14,8 +14,9 @@ By default, GitLab supports passwords with the following lengths:
 
 GitLab administrators can modify password lengths:
 
-- Using the GitLab UI. **[From](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20661) GitLab 12.6 this is the only available option.**
-- Using configuration file. **Up to GitLab 12.5**.
+- Using the GitLab UI. [From](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20661) GitLab
+  12.6, this is the only available option.
+- Using configuration file. Up to GitLab 12.5.
 
 Changing the minimum or maximum length does not affect existing user passwords. Existing users are
 not asked to reset their password to adhere to the new limits. The new limit restriction applies
@@ -29,7 +30,8 @@ The user password length is set to a minimum of 8 characters by default.
 
 To change the minimum password length using GitLab UI:
 
-1. Go to the Admin Area (**{admin}**) and select **Settings > Sign-up restrictions**.
+1. On the top bar, select **Menu >** **{admin}** **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

@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 `ssh-keygen` allows users to create RSA keys with as few as 768 bits, which
 falls well below recommendations from certain standards groups (such as the US
-NIST). Some organizations deploying GitLab will need to enforce minimum key
+NIST). Some organizations deploying GitLab need to enforce minimum key
 strength, either to satisfy internal security policy or for regulatory
 compliance.
 
@@ -18,14 +18,17 @@ the older DSA, and administrators may need to 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.
+the minimum key length for each technology:
 
-In **Admin Area > Settings** (`/admin/application_settings/general`), expand the
-**Visibility and access controls** section:
+1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the left sidebar, select **Settings > General** (`/admin/application_settings/general`).
+1. Expand the **Visibility and access controls** section:
 
-![SSH keys restriction admin settings](img/ssh_keys_restrictions_settings.png)
+   ![SSH keys restriction admin settings](img/ssh_keys_restrictions_settings.png)
 
-If a restriction is imposed on any key type, users cannot upload new SSH keys that don't meet the requirement. Any existing keys that don't meet it are disabled but not removed and users cannot to pull or push code using them.
+If a restriction is imposed on any key type, users cannot upload new SSH keys that don't meet the
+requirement. Any existing keys that don't meet it are disabled but not removed and users cannot to
+pull or push code using them.
 
 An icon is visible to the user of a restricted key in the SSH keys section of their profile:
 

doc/security/two_factor_authentication.md

@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 Two-factor Authentication (2FA) provides an additional level of security to your
 users' GitLab account. After being enabled, in addition to supplying their
-username and password to sign in, they'll be prompted for a code generated by an
+username and password to sign in, they are prompted for a code generated by an
 application on their phone.
 
 You can read more about it here:
@@ -28,8 +28,8 @@ cannot leave the 2FA configuration area at `/-/profile/two_factor_auth`.
 
 To enable 2FA for all users:
 
-1. Navigate to **Admin Area > Settings > General**
-   (`/admin/application_settings/general`).
+1. On the top bar, select **Menu >** **{admin}** **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.
 
 If you want 2FA enforcement to take effect during the next sign-in attempt,
@@ -39,13 +39,13 @@ change the grace period to `0`.
 
 > [Introduced in](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/24965) GitLab 12.0, 2FA settings for a group are also applied to subgroups.
 
-If you want to enforce 2FA only for certain groups, you can:
+If you want to enforce 2FA only for certain groups:
 
-1. Enable it in the group's **Settings > General** page. Navigate to
-   **Permissions, LFS, 2FA > Two-factor authentication**. You can then select
-   the **Require all users in this group to setup Two-factor authentication**
-   option.
-1. You can also specify a grace period in the **Time before enforced** option.
+1. Go to the group's **Settings > General** page.
+1. Expand the **Permissions, LFS, 2FA** section.
+1. Select the **Require all users in this group to setup two-factor authentication** option.
+
+You can also specify a grace period in the **Time before enforced** option.
 
 To change this setting, you need to be administrator or owner of the group.
 
@@ -67,8 +67,12 @@ The following are important notes about 2FA:
   2FA enabled, 2FA is **not** required for those individually added members.
 - If there are multiple 2FA requirements (for example, group + all users, or multiple
   groups) the shortest grace period is used.
-- It is possible to disallow subgroups from setting up their own 2FA requirements.
-  Navigate to the top-level group's **Settings > General > Permissions, LFS, 2FA > Two-factor authentication** and uncheck the **Allow subgroups to set up their own two-factor authentication rule** field. This action causes all subgroups with 2FA requirements to stop requiring that from their members.
+- It is possible to disallow subgroups from setting up their own 2FA requirements:
+  1. Go to the top-level group's **Settings > General**.
+  1. Expand the **Permissions, LFS, 2FA** section.
+  1. Uncheck the **Allow subgroups to set up their own two-factor authentication rule** field.
+
+  This action causes all subgroups with 2FA requirements to stop requiring that from their members.
 
 ## Disabling 2FA for everyone
 
@@ -93,18 +97,6 @@ WARNING:
 This is a permanent and irreversible action. Users have to
 reactivate 2FA from scratch if they want to use it again.
 
-<!-- ## Troubleshooting
-
-Include any troubleshooting steps that you can foresee. If you know beforehand what issues
-one might have when setting this up, or when something is changed, or on upgrading, it's
-important to describe those, too. Think of things that may go wrong and include them here.
-This is important to minimize requests for support, and to avoid doc comments with
-questions that you know someone might ask.
-
-Each scenario can be a third-level heading, e.g. `### Getting error message X`.
-If you have none to add when creating a doc, leave this section in place
-but commented out to help encourage others to add to it in the future. -->
-
 ## Two-factor Authentication (2FA) for Git over SSH operations **(PREMIUM)**
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/270554) in GitLab 13.7.
@@ -157,3 +149,15 @@ The feature flag affects these features:
 
 - [Two-factor Authentication (2FA) for Git over SSH operations](#two-factor-authentication-2fa-for-git-over-ssh-operations).
 - [Customize session duration for Git Operations when 2FA is enabled](../user/admin_area/settings/account_and_limit_settings.md#customize-session-duration-for-git-operations-when-2fa-is-enabled).
+
+<!-- ## Troubleshooting
+
+Include any troubleshooting steps that you can foresee. If you know beforehand what issues
+one might have when setting this up, or when something is changed, or on upgrading, it's
+important to describe those, too. Think of things that may go wrong and include them here.
+This is important to minimize requests for support, and to avoid doc comments with
+questions that you know someone might ask.
+
+Each scenario can be a third-level heading, e.g. `### Getting error message X`.
+If you have none to add when creating a doc, leave this section in place
+but commented out to help encourage others to add to it in the future. -->

doc/security/user_email_confirmation.md

@@ -11,8 +11,9 @@ 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.
 
-In **Admin Area > Settings** (`/admin/application_settings/general`), go to the section
-**Sign-up Restrictions** and look for the **Send confirmation email on sign-up** option.
+1. On the top bar, select **Menu >** **{admin}** **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.
 
 ## Confirmation token expiry
 

doc/user/admin_area/approving_users.md

@@ -34,7 +34,8 @@ sign in.
 
 To view user sign ups pending approval:
 
-1. Go to **Admin Area > Overview > Users**.
+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
@@ -43,9 +44,10 @@ A user sign up pending approval can be approved or rejected from the Admin Area.
 
 To approve or reject a user sign up:
 
-1. Go to  **Admin Area > Overview > Users**.
+1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the left sidebar, select **Overview > Users**.
 1. Select the **Pending approval** tab.
-1. In the user's row select settings (**{settings}**).
+1. In the user's row, select settings (**{settings}**).
 1. Select **Approve** or **Reject**.
 
 Approving a user:

doc/user/admin_area/credentials_inventory.md

@@ -9,7 +9,9 @@ type: howto
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20912) in GitLab 12.6.
 
-GitLab administrators are responsible for the overall security of their instance. To assist, GitLab provides a Credentials inventory to keep track of all the credentials that can be used to access their self-managed instance.
+GitLab administrators are responsible for the overall security of their instance. To assist, GitLab
+provides a Credentials inventory to keep track of all the credentials that can be used to access
+their self-managed instance.
 
 Using Credentials inventory, you can see all the personal access tokens (PAT), SSH keys, and GPG keys
 that exist in your GitLab instance. In addition, you can [revoke](#revoke-a-users-personal-access-token)
@@ -21,7 +23,10 @@ and [delete](#delete-a-users-ssh-key) and see:
 - When they expire. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/214809) in GitLab 13.2.
 - When they were revoked. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/214809) in GitLab 13.2.
 
-To access the Credentials inventory, navigate to **Admin Area > Credentials**.
+To access the Credentials inventory:
+
+1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the left sidebar, select **Credentials**.
 
 The following is an example of the Credentials inventory page:
 

doc/user/admin_area/moderate_users.md

@@ -21,9 +21,10 @@ 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. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the left sidebar, select **Overview > Users**.
 1. Select a user.
-1. Under the **Account** tab, click **Block user**.
+1. Under the **Account** tab, select **Block user**.
 
 A blocked user:
 
@@ -43,10 +44,11 @@ A blocked user does not consume a [seat](../../subscriptions/self_managed/index.
 
 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. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the left sidebar, select **Overview > Users**.
+1. Select on the **Blocked** tab.
 1. Select a user.
-1. Under the **Account** tab, click **Unblock user**.
+1. Under the **Account** tab, select **Unblock user**.
 
 Users can also be unblocked using the [GitLab API](../../api/users.md#unblock-user).
 
@@ -74,16 +76,17 @@ with the following differences:
 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).
+- Does not receive any notifications from GitLab.
+- Does 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. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the left sidebar, select **Overview > Users**.
 1. Select a user.
-1. Under the **Account** tab, click **Deactivate user**.
+1. Under the **Account** tab, select **Deactivate user**.
 
 Please note that for the deactivation option to be visible to an admin, the user:
 
@@ -99,11 +102,14 @@ A deactivated user does not consume a [seat](../../subscriptions/self_managed/in
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/320875) in GitLab 14.0.
 
-Administrators can enable automatic deactivation of users who have not signed in, or have no activity in the last 90 days. To do this:
+Administrators can enable automatic deactivation of users who have not signed in, or have no activity
+in the last 90 days. To do this:
 
-1. Navigate to  **Admin Area > Settings > General > Account and Limit**.
-1. Under the **Dormant users** tab, check **Deactivate dormant users after 90 days of inactivity**.
-1. Click **Save changes**.
+1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the left sidebar, select **Settings > General**.
+1. Expand the **Account and limit** section.
+1. Under **Dormant users**, check **Deactivate dormant users after 90 days of inactivity**.
+1. Select **Save changes**.
 
 When this feature is enabled, GitLab runs a job once a day to deactivate the dormant users.
 
@@ -117,10 +123,11 @@ 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. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the left sidebar, select **Overview > Users**.
+1. Select the **Deactivated** tab.
 1. Select a user.
-1. Under the **Account** tab, click **Activate user**.
+1. Under the **Account** tab, select **Activate user**.
 
 Users can also be activated using the [GitLab API](../../api/users.md#activate-user).
 
@@ -148,23 +155,25 @@ 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. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the left sidebar, select **Overview > Users**.
 1. Select a user.
-1. Under the **Account** tab, click **Ban user**.
+1. Under the **Account** tab, select **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.
+This functionality is planned to 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. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the left sidebar, select **Overview > Users**.
+1. Select the **Banned** tab.
 1. Select a user.
-1. Under the **Account** tab, click **Unban user**.
+1. Under the **Account** tab, select **Unban user**.
 
 NOTE:
 Unbanning a user changes the user's state to active and consumes a

doc/user/admin_area/review_abuse_reports.md

@@ -16,7 +16,8 @@ reports in the Admin Area.
 
 To receive notifications of new abuse reports by e-mail, follow these steps:
 
-1. Select **Admin Area > Settings >  Reporting**.
+1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the left sidebar, select **Settings > Reporting**.
 1. Expand the **Abuse reports** section.
 1. Provide an email address.
 
@@ -30,7 +31,10 @@ documentation](../report_abuse.md).
 
 ## Resolving abuse reports
 
-To access abuse reports, go to **Admin Area > Abuse Reports**.
+To access abuse reports:
+
+1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the left sidebar, select **Abuse Reports**.
 
 There are 3 ways to resolve an abuse report, with a button for each method:
 

doc/user/group/subgroups/index.md

@@ -67,8 +67,6 @@ Another example of GitLab as a company would be the following:
     - (project) Chef cookbooks
   - Category Subgroup - Executive team
 
----
-
 When performing actions such as transferring or importing a project between
 subgroups, the behavior is the same as when performing these actions at the
 `group/project` level.
@@ -85,13 +83,20 @@ By default, groups created in:
 
 The setting can be changed for any group by:
 
-- A group owner. Select the group, and navigate to **Settings > General > Permissions, LFS, 2FA**.
-- An administrator. Navigate to **Admin Area > Overview > Groups**, select the group, and choose **Edit**.
+- A group owner:
+  1. Select the group.
+  1. On the left sidebar, select **Settings > General**.
+  1. Expand the **Permissions, LFS, 2FA** section.
+- An administrator:
+  1. On the top bar, select **Menu >** **{admin}** **Admin**.
+  1. On the left sidebar, select **Overview > Groups**.
+  1. Select the group, and select **Edit**.
+
+For:
 
-For more information check the
-[permissions table](../../permissions.md#group-members-permissions). For a list
-of words that are not allowed to be used as group names see the
-[reserved names](../../reserved_names.md).
+- More information, check the [permissions table](../../permissions.md#group-members-permissions).
+- A list of words that are not allowed to be used as group names, see the
+  [reserved names](../../reserved_names.md).
 
 Users can always create subgroups if they are explicitly added as an Owner (or
 Maintainer, if that setting is enabled) to an immediate parent group, even if group

doc/user/permissions.md

@@ -359,10 +359,11 @@ External users still count towards a license seat.
 
 An administrator can flag a user as external by either of the following methods:
 
-- Either [through the API](../api/users.md#user-modification).
-- Or by navigating to the **Admin Area > Overview > Users** to create a new user
-  or edit an existing one. There, you can find the option to flag the user as
-  external.
+- [Through the API](../api/users.md#user-modification).
+- Using the GitLab UI:
+  1. On the top bar, select **Menu >** **{admin}** **Admin**.
+  1. On the left sidebar, select **Overview > Users** to create a new user or edit an existing one.
+     There, you can find the option to flag the user as external.
 
 Additionally users can be set as external users using [SAML groups](../integration/saml.md#external-groups)
 and [LDAP groups](../administration/auth/ldap/index.md#external-groups).
@@ -370,7 +371,11 @@ and [LDAP groups](../administration/auth/ldap/index.md#external-groups).
 ### Setting new users to external
 
 By default, new users are not set as external users. This behavior can be changed
-by an administrator on the **Admin Area > Settings > General** page, under **Account and limit**.
+by an administrator:
+
+1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the left sidebar, select **Settings > General**.
+1. Expand the **Account and limit** section.
 
 If you change the default behavior of creating new users as external, you
 have the option to narrow it down by defining a set of internal users.

doc/user/profile/account/create_accounts.md

@@ -14,16 +14,21 @@ You can create users:
 
 ## Create users on sign in page
 
-If you have [sign-up enabled](../../admin_area/settings/sign_up_restrictions.md), users can create their own accounts by selecting "Register now" on the sign-in page, or navigate to `https://gitlab.example.com/users/sign_up`.
+If you have [sign-up enabled](../../admin_area/settings/sign_up_restrictions.md), users can create
+their own accounts by either:
+
+- Selecting the **Register now** link on the sign-in page.
+- Navigating to `https://gitlab.example.com/users/sign_up`.
 
 ![Register Tab](img/register_v13_6.png)
 
 ## Create users in Admin Area
 
-As an admin user, you can manually create users by:
+As an Admin user, you can manually create users:
 
-1. Navigating to **Admin Area > Overview > Users** (`/admin/users` page).
-1. Selecting the **New User** button.
+1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the left sidebar, select **Overview > Users** (`/admin/users`).
+1. Select **New user**.
 
 You can also [create users through the API](../../../api/users.md) as an admin.
 
@@ -33,9 +38,11 @@ You can also [create users through the API](../../../api/users.md) as an admin.
 
 ## Create users through authentication integrations
 
-Users will be:
+Users are:
 
 - Automatically created upon first sign in with the [LDAP integration](../../../administration/auth/ldap/index.md).
-- Created when first signing in via an [OmniAuth provider](../../../integration/omniauth.md) if the `allow_single_sign_on` setting is present.
-- Created when first signing with [Group SAML](../../group/saml_sso/index.md)
-- Automatically created by [SCIM](../../group/saml_sso/scim_setup.md) when the user is created in the identity provider.
+- Created when first signing in using an [OmniAuth provider](../../../integration/omniauth.md) if
+  the `allow_single_sign_on` setting is present.
+- Created when first signing with [Group SAML](../../group/saml_sso/index.md).
+- Automatically created by [SCIM](../../group/saml_sso/scim_setup.md) when the user is created in
+  the identity provider.

doc/user/profile/account/delete_account.md

@@ -13,7 +13,7 @@ Users can be deleted from a GitLab instance, either by:
 - An administrator.
 
 NOTE:
-Deleting a user will delete all projects in that user namespace.
+Deleting a user deletes all projects in that user namespace.
 
 ## As a user
 
@@ -28,7 +28,8 @@ As a user, to delete your own account:
 
 As an administrator, to delete a user account:
 
-1. Go to **Admin Area > Overview > Users**.
+1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the left sidebar, select **Overview > Users**.
 1. Select a user.
 1. Under the **Account** tab, select:
    - **Delete user** to delete only the user but maintain their