Add latest changes from gitlab-org/gitlab@master

51 files changed, 253 insertions, 149 deletions

diff --git a/app/assets/javascripts/incidents/components/incidents_list.vue b/app/assets/javascripts/incidents/components/incidents_list.vue
index c1a73ba56f7..4cd86c4b8b9 100644
--- a/app/assets/javascripts/incidents/components/incidents_list.vue
+++ b/app/assets/javascripts/incidents/components/incidents_list.vue
@@ -9,6 +9,7 @@ import {
   GlTooltipDirective,
   GlButton,
   GlSearchBoxByType,
+  GlIcon,
 } from '@gitlab/ui';
 import { debounce } from 'lodash';
 import TimeAgoTooltip from '~/vue_shared/components/time_ago_tooltip.vue';
@@ -55,6 +56,7 @@ export default {
     GlButton,
     TimeAgoTooltip,
     GlSearchBoxByType,
+    GlIcon,
   },
   directives: {
     GlTooltip: GlTooltipDirective,
@@ -164,7 +166,15 @@ export default {
       @row-clicked="navigateToIncidentDetails"
     >
       <template #cell(title)="{ item }">
-        <div class="gl-max-w-full text-truncate" :title="item.title">{{ item.title }}</div>
+        <div class="gl-display-flex gl-justify-content-center">
+          <div class="gl-max-w-full text-truncate" :title="item.title">{{ item.title }}</div>
+          <gl-icon
+            v-if="item.state === 'closed'"
+            name="issue-close"
+            class="gl-fill-blue-500"
+            data-testid="incident-closed"
+          />
+        </div>
       </template>
 
       <template #cell(createdAt)="{ item }">
diff --git a/app/assets/javascripts/incidents/graphql/queries/get_incidents.query.graphql b/app/assets/javascripts/incidents/graphql/queries/get_incidents.query.graphql
index e025a764c34..eeba60139ca 100644
--- a/app/assets/javascripts/incidents/graphql/queries/get_incidents.query.graphql
+++ b/app/assets/javascripts/incidents/graphql/queries/get_incidents.query.graphql
@@ -10,6 +10,7 @@ query getIncidents(
         iid
         title
         createdAt
+        state
         labels {
           nodes {
             title
diff --git a/app/assets/javascripts/jira_import/components/jira_import_form.vue b/app/assets/javascripts/jira_import/components/jira_import_form.vue
index 24bfb49a7d1..eb72e8581e8 100644
--- a/app/assets/javascripts/jira_import/components/jira_import_form.vue
+++ b/app/assets/javascripts/jira_import/components/jira_import_form.vue
@@ -189,11 +189,10 @@ export default {
       <p>
         {{
           __(
-            `Jira users have been matched with similar GitLab users.
-            This can be overwritten by selecting a GitLab user from the dropdown in the "GitLab
+            `Jira users have been imported from the configured Jira instance.
+            They can be mapped by selecting a GitLab user from the dropdown in the "GitLab
             username" column.
-            If it wasn't possible to match a Jira user with a GitLab user, the dropdown defaults to
-            the user conducting the import.`,
+            When the form appears, the dropdown defaults to the user conducting the import.`,
           )
         }}
       </p>
diff --git a/app/controllers/invites_controller.rb b/app/controllers/invites_controller.rb
index 5bd9ac7f275..83920f38ab4 100644
--- a/app/controllers/invites_controller.rb
+++ b/app/controllers/invites_controller.rb
@@ -4,6 +4,7 @@ class InvitesController < ApplicationController
   include Gitlab::Utils::StrongMemoize
 
   before_action :member
+  before_action :invite_details
   skip_before_action :authenticate_user!, only: :decline
 
   helper_method :member?, :current_user_matches_invite?
@@ -16,9 +17,8 @@ class InvitesController < ApplicationController
 
   def accept
     if member.accept_invite!(current_user)
-      label, path = source_info(member.source)
-
-      redirect_to path, notice: _("You have been granted %{member_human_access} access to %{label}.") % { member_human_access: member.human_access, label: label }
+      redirect_to invite_details[:path], notice: _("You have been granted %{member_human_access} access to %{title} %{name}.") %
+        { member_human_access: member.human_access, title: invite_details[:title], name: invite_details[:name] }
     else
       redirect_back_or_default(options: { alert: _("The invitation could not be accepted.") })
     end
@@ -26,8 +26,6 @@ class InvitesController < ApplicationController
 
   def decline
     if member.decline_invite!
-      label, _ = source_info(member.source)
-
       path =
         if current_user
           dashboard_projects_path
@@ -35,7 +33,8 @@ class InvitesController < ApplicationController
           new_user_session_path
         end
 
-      redirect_to path, notice: _("You have declined the invitation to join %{label}.") % { label: label }
+      redirect_to path, notice: _("You have declined the invitation to join %{title} %{name}.") %
+        { title: invite_details[:title], name: invite_details[:name] }
     else
       redirect_back_or_default(options: { alert: _("The invitation could not be declined.") })
     end
@@ -79,21 +78,22 @@ class InvitesController < ApplicationController
     redirect_to new_user_session_path, notice: notice
   end
 
-  def source_info(source)
-    case source
-    when Project
-      project = member.source
-      label = "project #{project.full_name}"
-      path = project_path(project)
-    when Group
-      group = member.source
-      label = "group #{group.name}"
-      path = group_path(group)
-    else
-      label = "who knows what"
-      path = dashboard_projects_path
-    end
-
-    [label, path]
+  def invite_details
+    @invite_details ||= case @member.source
+                        when Project
+                          {
+                            name: @member.source.full_name,
+                            url: project_url(@member.source),
+                            title: _("project"),
+                            path: project_path(@member.source)
+                          }
+                        when Group
+                          {
+                            name: @member.source.name,
+                            url: group_url(@member.source),
+                            title: _("group"),
+                            path: group_path(@member.source)
+                          }
+                        end
   end
 end
diff --git a/app/views/invites/show.html.haml b/app/views/invites/show.html.haml
index 2bcd64d0690..283683511d7 100644
--- a/app/views/invites/show.html.haml
+++ b/app/views/invites/show.html.haml
@@ -2,28 +2,19 @@
 %h3.page-title= _("Invitation")
 
 %p
-  You have been invited
-  - if inviter = @member.created_by
-    by
+  = _("You have been invited")
+  - inviter = @member.created_by
+  - if inviter
+    = _("by")
     = link_to inviter.name, user_url(inviter)
-  to join
-  - case @member.source
-  - when Project
-    - project = @member.source
-    project
-    %strong
-      = link_to project.full_name, project_url(project)
-  - when Group
-    - group = @member.source
-    group
-    %strong
-      = link_to group.name, group_url(group)
-  as #{@member.human_access}.
+  = _("to join %{source_name}") % { source_name: @invite_details[:title] }
+  %strong
+    = link_to @invite_details[:name], @invite_details[:url]
+  = _("as %{role}.") % { role: @member.human_access }
 
 - if member?
   %p
-    - member_source = @member.source.is_a?(Group) ? _("group") : _("project")
-    = _("However, you are already a member of this %{member_source}. Sign in using a different account to accept the invitation.") % { member_source: member_source }
+    = _("However, you are already a member of this %{member_source}. Sign in using a different account to accept the invitation.") % { member_source: @invite_details[:title] }
 
 - if !current_user_matches_invite?
   %p
@@ -32,7 +23,7 @@
     - link_to_current_user = link_to(current_user.to_reference, user_url(current_user))
     = _("Note that this invitation was sent to %{mail_to_invite_email}, but you are signed in as %{link_to_current_user} with email %{mail_to_current_user}.").html_safe % { mail_to_invite_email: mail_to_invite_email, mail_to_current_user: mail_to_current_user, link_to_current_user: link_to_current_user }
 
-- unless member?
+- if !member?
   .actions
     = link_to _("Accept invitation"), accept_invite_url(@token), method: :post, class: "btn btn-success"
     = link_to _("Decline"), decline_invite_url(@token), method: :post, class: "btn btn-danger gl-ml-3"
diff --git a/changelogs/unreleased/229401-close-icon.yml b/changelogs/unreleased/229401-close-icon.yml
new file mode 100644
index 00000000000..bcec77406ba
--- /dev/null
+++ b/changelogs/unreleased/229401-close-icon.yml
@@ -0,0 +1,5 @@
+---
+title: Add closed issue icon to incidents list for closed incidents
+merge_request: 37949
+author:
+type: changed
diff --git a/db/fixtures/development/28_integrations.rb b/db/fixtures/development/28_integrations.rb
new file mode 100644
index 00000000000..db54593ae27
--- /dev/null
+++ b/db/fixtures/development/28_integrations.rb
@@ -0,0 +1,28 @@
+# frozen_string_literal: true
+
+Gitlab::Seeder.quiet do
+  # This is only enabled if you're going to be using the customer portal in
+  # development.
+  # CUSTOMER_PORTAL_URL=https://your.ngrok.io FILTER=integrations rake db:seed_fu
+  flag = 'CUSTOMER_PORTAL_URL'
+
+  if ENV[flag]
+    ApplicationSetting.current_without_cache.update!(check_namespace_plan: true)
+
+    print '.'
+
+    Doorkeeper::Application.create!(
+      name: 'Customer Portal Development',
+      uid: '28cc28f03b415fbc737a7364dc06af0adf12688e1b0c6669baf6850a6855132b',
+      secret: '74c96596ec3f82dd137dd5775f31eba919f77b0a3114611f0411d148d727c64c',
+      redirect_uri: "#{ENV['CUSTOMER_PORTAL_URL']}/auth/gitlab/callback",
+      scopes: 'api read_user openid',
+      trusted: true,
+      confidential: true
+    )
+
+    print '.'
+  else
+    puts "Skipped. To enable, set the `#{flag}` environment variable to your development customer's portal url."
+  end
+end
diff --git a/doc/administration/geo/disaster_recovery/background_verification.md b/doc/administration/geo/disaster_recovery/background_verification.md
index 88218d24b2f..c51634fd597 100644
--- a/doc/administration/geo/disaster_recovery/background_verification.md
+++ b/doc/administration/geo/disaster_recovery/background_verification.md
@@ -58,14 +58,14 @@ Feature.enable('geo_repository_verification')
 
 ## Repository verification
 
-Navigate to the **{admin}** **Admin Area >** **{location-dot}** **Geo** dashboard on the **primary** node and expand
+Navigate to the **Admin Area >** **{location-dot}** **Geo** dashboard on the **primary** node and expand
 the **Verification information** tab for that node to view automatic checksumming
 status for repositories and wikis. Successes are shown in green, pending work
 in gray, and failures in red.
 
 ![Verification status](img/verification-status-primary.png)
 
-Navigate to the **{admin}** **Admin Area >** **{location-dot}** **Geo** dashboard on the **secondary** node and expand
+Navigate to the **Admin Area >** **{location-dot}** **Geo** dashboard on the **secondary** node and expand
 the **Verification information** tab for that node to view automatic verification
 status for repositories and wikis. As with checksumming, successes are shown in
 green, pending work in gray, and failures in red.
@@ -92,7 +92,7 @@ data. The default and recommended re-verification interval is 7 days, though
 an interval as short as 1 day can be set. Shorter intervals reduce risk but
 increase load and vice versa.
 
-Navigate to the **{admin}** **Admin Area >** **{location-dot}** **Geo** dashboard on the **primary** node, and
+Navigate to the **Admin Area >** **{location-dot}** **Geo** dashboard on the **primary** node, and
 click the **Edit** button for the **primary** node to customize the minimum
 re-verification interval:
 
@@ -141,7 +141,7 @@ sudo gitlab-rake geo:verification:wiki:reset
 
 If the **primary** and **secondary** nodes have a checksum verification mismatch, the cause may not be apparent. To find the cause of a checksum mismatch:
 
-1. Navigate to the **{admin}** **Admin Area >** **{overview}** **Overview > Projects** dashboard on the **primary** node, find the
+1. Navigate to the **Admin Area >** **{overview}** **Overview > Projects** dashboard on the **primary** node, find the
    project that you want to check the checksum differences and click on the
    **Edit** button:
    ![Projects dashboard](img/checksum-differences-admin-projects.png)
diff --git a/doc/administration/geo/disaster_recovery/planned_failover.md b/doc/administration/geo/disaster_recovery/planned_failover.md
index ef0e67434d0..817f6859322 100644
--- a/doc/administration/geo/disaster_recovery/planned_failover.md
+++ b/doc/administration/geo/disaster_recovery/planned_failover.md
@@ -110,7 +110,7 @@ The maintenance window won't end until Geo replication and verification is
 completely finished. To keep the window as short as possible, you should
 ensure these processes are close to 100% as possible during active use.
 
-Navigate to the **{admin}** **Admin Area >** **{location-dot}** **Geo** dashboard on the **secondary** node to
+Navigate to the **Admin Area >** **{location-dot}** **Geo** dashboard on the **secondary** node to
 review status. Replicated objects (shown in green) should be close to 100%,
 and there should be no failures (shown in red). If a large proportion of
 objects aren't yet replicated (shown in gray), consider giving the node more
@@ -135,8 +135,8 @@ This [content was moved to another location](background_verification.md).
 
 ### Notify users of scheduled maintenance
 
-On the **primary** node, navigate to **{admin}** **Admin Area >** **{bullhorn}** **Messages**, add a broadcast
-message. You can check under **{admin}** **Admin Area >** **{location-dot}** **Geo** to estimate how long it
+On the **primary** node, navigate to **Admin Area >** **{bullhorn}** **Messages**, add a broadcast
+message. You can check under **Admin Area >** **{location-dot}** **Geo** to estimate how long it
 will take to finish syncing. An example message would be:
 
 > A scheduled maintenance will take place at XX:XX UTC. We expect it to take
@@ -181,7 +181,7 @@ access to the **primary** node during the maintenance window.
    connection.
 
 1. Disable non-Geo periodic background jobs on the **primary** node by navigating
-   to **{admin}** **Admin Area >** **{monitor}** **Monitoring > Background Jobs > Cron**, pressing `Disable All`,
+   to **Admin Area >** **{monitor}** **Monitoring > Background Jobs > Cron**, pressing `Disable All`,
    and then pressing `Enable` for the `geo_sidekiq_cron_config_worker` cron job.
    This job will re-enable several other cron jobs that are essential for planned
    failover to complete successfully.
@@ -190,11 +190,11 @@ access to the **primary** node during the maintenance window.
 
 1. If you are manually replicating any data not managed by Geo, trigger the
    final replication process now.
-1. On the **primary** node, navigate to **{admin}** **Admin Area >** **{monitor}** **Monitoring > Background Jobs > Queues**
+1. On the **primary** node, navigate to **Admin Area >** **{monitor}** **Monitoring > Background Jobs > Queues**
    and wait for all queues except those with `geo` in the name to drop to 0.
    These queues contain work that has been submitted by your users; failing over
    before it is completed will cause the work to be lost.
-1. On the **primary** node, navigate to **{admin}** **Admin Area >** **{location-dot}** **Geo** and wait for the
+1. On the **primary** node, navigate to **Admin Area >** **{location-dot}** **Geo** and wait for the
    following conditions to be true of the **secondary** node you are failing over to:
 
    - All replication meters to each 100% replicated, 0% failures.
@@ -202,7 +202,7 @@ access to the **primary** node during the maintenance window.
    - Database replication lag is 0ms.
    - The Geo log cursor is up to date (0 events behind).
 
-1. On the **secondary** node, navigate to **{admin}** **Admin Area >** **{monitor}** **Monitoring > Background Jobs > Queues**
+1. On the **secondary** node, navigate to **Admin Area >** **{monitor}** **Monitoring > Background Jobs > Queues**
    and wait for all the `geo` queues to drop to 0 queued and 0 running jobs.
 1. On the **secondary** node, use [these instructions](../../raketasks/check.md)
    to verify the integrity of CI artifacts, LFS objects, and uploads in file
diff --git a/doc/administration/geo/replication/configuration.md b/doc/administration/geo/replication/configuration.md
index 3d08ed81700..8b8c8071292 100644
--- a/doc/administration/geo/replication/configuration.md
+++ b/doc/administration/geo/replication/configuration.md
@@ -191,7 +191,7 @@ keys must be manually replicated to the **secondary** node.
    gitlab-ctl reconfigure
    ```
 
-1. Visit the **primary** node's **{admin}** **Admin Area >** **{location-dot}** **Geo**
+1. Visit the **primary** node's **Admin Area >** **{location-dot}** **Geo**
    (`/admin/geo/nodes`) in your browser.
 1. Click the **New node** button.
    ![Add secondary node](img/adding_a_secondary_node.png)
@@ -238,7 +238,7 @@ You can login to the **secondary** node with the same credentials as used for th
 Using Hashed Storage significantly improves Geo replication. Project and group
 renames no longer require synchronization between nodes.
 
-1. Visit the **primary** node's **{admin}** **Admin Area >** **{settings}** **Settings > Repository**
+1. Visit the **primary** node's **Admin Area >** **{settings}** **Settings > Repository**
    (`/admin/application_settings/repository`) in your browser.
 1. In the **Repository storage** section, check **Use hashed storage paths for newly created and renamed projects**.
 
@@ -255,7 +255,7 @@ on the **secondary** node.
 ### Step 6. Enable Git access over HTTP/HTTPS
 
 Geo synchronizes repositories over HTTP/HTTPS, and therefore requires this clone
-method to be enabled. Navigate to **{admin}** **Admin Area >** **{settings}** **Settings**
+method to be enabled. Navigate to **Admin Area >** **{settings}** **Settings**
 (`/admin/application_settings/general`) on the **primary** node, and set
 `Enabled Git access protocols` to `Both SSH and HTTP(S)` or `Only HTTP(S)`.
 
@@ -264,7 +264,7 @@ method to be enabled. Navigate to **{admin}** **Admin Area >** **{settings}** **
 Your **secondary** node is now configured!
 
 You can login to the **secondary** node with the same credentials you used for the
-**primary** node. Visit the **secondary** node's **{admin}** **Admin Area >** **{location-dot}** **Geo**
+**primary** node. Visit the **secondary** node's **Admin Area >** **{location-dot}** **Geo**
 (`/admin/geo/nodes`) in your browser to check if it's correctly identified as a
 **secondary** Geo node and if Geo is enabled.
 
diff --git a/doc/administration/geo/replication/disable_geo.md b/doc/administration/geo/replication/disable_geo.md
index f53b4c1b796..cbbbf559374 100644
--- a/doc/administration/geo/replication/disable_geo.md
+++ b/doc/administration/geo/replication/disable_geo.md
@@ -33,7 +33,7 @@ in order to do that.
 
 ## Remove the primary node from the UI
 
-1. Go to **{admin}** **Admin Area >** **{location-dot}** **Geo** (`/admin/geo/nodes`).
+1. Go to **Admin Area >** **{location-dot}** **Geo** (`/admin/geo/nodes`).
 1. Click the **Remove** button for the **primary** node.
 1. Confirm by clicking **Remove** when the prompt appears.
 
diff --git a/doc/administration/geo/replication/docker_registry.md b/doc/administration/geo/replication/docker_registry.md
index c34732cba67..75ddbe4e813 100644
--- a/doc/administration/geo/replication/docker_registry.md
+++ b/doc/administration/geo/replication/docker_registry.md
@@ -122,7 +122,7 @@ generate a short-lived JWT that is pull-only-capable to access the
 
 ### Verify replication
 
-To verify Container Registry replication is working, go to **{admin}** **Admin Area >** **{location-dot}** **Geo**
+To verify Container Registry replication is working, go to **Admin Area >** **{location-dot}** **Geo**
 (`/admin/geo/nodes`) on the **secondary** node.
 The initial replication, or "backfill", will probably still be in progress.
 You can monitor the synchronization process on each Geo node from the **primary** node's **Geo Nodes** dashboard in your browser.
diff --git a/doc/administration/geo/replication/object_storage.md b/doc/administration/geo/replication/object_storage.md
index 3cc0ade414e..65e320dbf92 100644
--- a/doc/administration/geo/replication/object_storage.md
+++ b/doc/administration/geo/replication/object_storage.md
@@ -33,7 +33,7 @@ whether they are stored on the local filesystem or in object storage.
 
 To enable GitLab replication, you must:
 
-1. Go to **{admin}** **Admin Area >** **{location-dot}** **Geo**.
+1. Go to **Admin Area >** **{location-dot}** **Geo**.
 1. Press **Edit** on the **secondary** node.
 1. Enable the **Allow this secondary node to replicate content on Object Storage**
    checkbox.
diff --git a/doc/administration/geo/replication/remove_geo_node.md b/doc/administration/geo/replication/remove_geo_node.md
index 539132776b3..9db1d88a11f 100644
--- a/doc/administration/geo/replication/remove_geo_node.md
+++ b/doc/administration/geo/replication/remove_geo_node.md
@@ -9,7 +9,7 @@ type: howto
 
 **Secondary** nodes can be removed from the Geo cluster using the Geo admin page of the **primary** node. To remove a **secondary** node:
 
-1. Navigate to **{admin}** **Admin Area >** **{location-dot}** **Geo** (`/admin/geo/nodes`).
+1. Navigate to **Admin Area >** **{location-dot}** **Geo** (`/admin/geo/nodes`).
 1. Click the **Remove** button for the **secondary** node you want to remove.
 1. Confirm by clicking **Remove** when the prompt appears.
 
diff --git a/doc/administration/geo/replication/troubleshooting.md b/doc/administration/geo/replication/troubleshooting.md
index 4f3528c7ae4..421eb88b017 100644
--- a/doc/administration/geo/replication/troubleshooting.md
+++ b/doc/administration/geo/replication/troubleshooting.md
@@ -26,7 +26,7 @@ Before attempting more advanced troubleshooting:
 
 ### Check the health of the **secondary** node
 
-Visit the **primary** node's **{admin}** **Admin Area >** **{location-dot}** **Geo** (`/admin/geo/nodes`) in
+Visit the **primary** node's **Admin Area >** **{location-dot}** **Geo** (`/admin/geo/nodes`) in
 your browser. We perform the following health checks on each **secondary** node
 to help identify if something is wrong:
 
@@ -132,8 +132,7 @@ Geo finds the current machine's Geo node name in `/etc/gitlab/gitlab.rb` by:
 - Using the `gitlab_rails['geo_node_name']` setting.
 - If that is not defined, using the `external_url` setting.
 
-This name is used to look up the node with the same **Name** in
-**{admin}** **Admin Area >** **{location-dot}** **Geo**.
+This name is used to look up the node with the same **Name** in **Admin Area >** **{location-dot}** **Geo**.
 
 To check if the current machine has a node name that matches a node in the
 database, run the check task:
@@ -840,7 +839,7 @@ If you are able to log in to the **primary** node, but you receive this error
 when attempting to log into a **secondary**, you should check that the Geo
 node's URL matches its external URL.
 
-1. On the primary, visit **{admin}** **Admin Area >** **{location-dot}** **Geo**.
+1. On the primary, visit **Admin Area >** **{location-dot}** **Geo**.
 1. Find the affected **secondary** and click **Edit**.
 1. Ensure the **URL** field matches the value found in `/etc/gitlab/gitlab.rb`
    in `external_url "https://gitlab.example.com"` on the frontend server(s) of
diff --git a/doc/administration/geo/replication/tuning.md b/doc/administration/geo/replication/tuning.md
index 63a8f81eecb..0e2b0a3fcb6 100644
--- a/doc/administration/geo/replication/tuning.md
+++ b/doc/administration/geo/replication/tuning.md
@@ -9,7 +9,7 @@ type: howto
 
 ## Changing the sync capacity values
 
-In the Geo admin page at **{admin}** **Admin Area >** **{location-dot}** **Geo** (`/admin/geo/nodes`),
+In the Geo admin page at **Admin Area >** **{location-dot}** **Geo** (`/admin/geo/nodes`),
 there are several variables that can be tuned to improve performance of Geo:
 
 - Repository sync capacity.
diff --git a/doc/administration/geo/replication/version_specific_updates.md b/doc/administration/geo/replication/version_specific_updates.md
index 777de715a8c..0f36e2e0797 100644
--- a/doc/administration/geo/replication/version_specific_updates.md
+++ b/doc/administration/geo/replication/version_specific_updates.md
@@ -214,7 +214,7 @@ Replicating over SSH has been deprecated, and support for this option will be
 removed in a future release.
 
 To switch to HTTP/HTTPS replication, log into the **primary** node as an admin and visit
-**{admin}** **Admin Area >** **{location-dot}** **Geo** (`/admin/geo/nodes`). For each **secondary** node listed,
+**Admin Area >** **{location-dot}** **Geo** (`/admin/geo/nodes`). For each **secondary** node listed,
 press the "Edit" button, change the "Repository cloning" setting from
 "SSH (deprecated)" to "HTTP/HTTPS", and press "Save changes". This should take
 effect immediately.
diff --git a/doc/administration/integration/terminal.md b/doc/administration/integration/terminal.md
index fd9e09dc17a..49766c98575 100644
--- a/doc/administration/integration/terminal.md
+++ b/doc/administration/integration/terminal.md
@@ -98,4 +98,4 @@ they will receive a `Connection failed` message.
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/8413) in GitLab 8.17.
 
 Terminal sessions, by default, do not expire.
-You can limit terminal session lifetime in your GitLab instance. To do so, navigate to **{admin}** [**Admin Area > Settings > Web terminal**](../../user/admin_area/settings/index.md#general), and set a `max session time`.
+You can limit terminal session lifetime in your GitLab instance. To do so, navigate to [**Admin Area > Settings > Web terminal**](../../user/admin_area/settings/index.md#general), and set a `max session time`.
diff --git a/doc/administration/monitoring/performance/grafana_configuration.md b/doc/administration/monitoring/performance/grafana_configuration.md
index 96f1377fb73..136a2749e80 100644
--- a/doc/administration/monitoring/performance/grafana_configuration.md
+++ b/doc/administration/monitoring/performance/grafana_configuration.md
@@ -68,7 +68,7 @@ repository.
 After setting up Grafana, you can enable a link to access it easily from the
 GitLab sidebar:
 
-1. Navigate to the **{admin}** **Admin Area > Settings > Metrics and profiling**.
+1. Navigate to the **Admin Area > Settings > Metrics and profiling**.
 1. Expand **Metrics - Grafana**.
 1. Check the **Enable access to Grafana** checkbox.
 1. Configure the **Grafana URL**:
@@ -77,7 +77,7 @@ GitLab sidebar:
    - *Otherwise,* enter the full URL of the Grafana instance.
 1. Click **Save changes**.
 
-GitLab displays your link in the **{admin}** **Admin Area > Monitoring > Metrics Dashboard**.
+GitLab displays your link in the **Admin Area > Monitoring > Metrics Dashboard**.
 
 ## Security Update
 
diff --git a/doc/administration/monitoring/performance/performance_bar.md b/doc/administration/monitoring/performance/performance_bar.md
index 8002a9ab296..bbaede0bd39 100644
--- a/doc/administration/monitoring/performance/performance_bar.md
+++ b/doc/administration/monitoring/performance/performance_bar.md
@@ -72,7 +72,7 @@ Requests with warnings display `(!)` after their path in the **Request selector*
 The GitLab Performance Bar is disabled by default. To enable it for a given group:
 
 1. Sign in as a user with Administrator [permissions](../../../user/permissions.md).
-1. In the menu bar, click the **{admin}** **Admin Area** icon.
+1. In the menu bar, click **Admin Area**.
 1. Navigate to **{settings}** **Settings > Metrics and profiling**
    (`admin/application_settings/metrics_and_profiling`), and expand the section
    **Profiling - Performance bar**.
diff --git a/doc/administration/monitoring/performance/request_profiling.md b/doc/administration/monitoring/performance/request_profiling.md
index a3b29493d84..20cb52fcaea 100644
--- a/doc/administration/monitoring/performance/request_profiling.md
+++ b/doc/administration/monitoring/performance/request_profiling.md
@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 To profile a request:
 
 1. Sign in to GitLab as a user with Administrator or Maintainer [permissions](../../../user/permissions.md).
-1. In the navigation bar, click **{admin}** **Admin area**.
+1. In the navigation bar, click **Admin area**.
 1. Navigate to **{monitor}** **Monitoring > Requests Profiles**.
 1. In the **Requests Profiles** section, copy the token.
 1. Pass the headers `X-Profile-Token: <token>` and `X-Profile-Mode: <mode>`(where
diff --git a/doc/administration/monitoring/prometheus/gitlab_metrics.md b/doc/administration/monitoring/prometheus/gitlab_metrics.md
index ddd1e53f18b..9cf00216a1a 100644
--- a/doc/administration/monitoring/prometheus/gitlab_metrics.md
+++ b/doc/administration/monitoring/prometheus/gitlab_metrics.md
@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 To enable the GitLab Prometheus metrics:
 
 1. Log into GitLab as a user with [administrator permissions](../../../user/permissions.md).
-1. Navigate to **{admin}** **Admin Area > Settings > Metrics and profiling**.
+1. Navigate to **Admin Area > Settings > Metrics and profiling**.
 1. Find the **Metrics - Prometheus** section, and click **Enable Prometheus Metrics**.
 1. [Restart GitLab](../../restart_gitlab.md#omnibus-gitlab-restart) for the changes to take effect.
 
diff --git a/doc/administration/operations/extra_sidekiq_processes.md b/doc/administration/operations/extra_sidekiq_processes.md
index 155680354da..e589ecc4216 100644
--- a/doc/administration/operations/extra_sidekiq_processes.md
+++ b/doc/administration/operations/extra_sidekiq_processes.md
@@ -82,7 +82,7 @@ To start multiple processes:
    ```
 
 After the extra Sidekiq processes are added, navigate to
-**{admin}** **Admin Area > Monitoring > Background Jobs** (`/admin/background_jobs`) in GitLab.
+**Admin Area > Monitoring > Background Jobs** (`/admin/background_jobs`) in GitLab.
 
 ![Multiple Sidekiq processes](img/sidekiq-cluster.png)
 
diff --git a/doc/administration/raketasks/project_import_export.md b/doc/administration/raketasks/project_import_export.md
index b807e03b01f..29bbe5261c6 100644
--- a/doc/administration/raketasks/project_import_export.md
+++ b/doc/administration/raketasks/project_import_export.md
@@ -46,6 +46,6 @@ Note the following:
   compatible as described in the [Version history](../../user/project/settings/import_export.md#version-history).
 - The project import option must be enabled in
   application settings (`/admin/application_settings/general`) under **Import sources**, which is available
-  under **{admin}** **Admin Area >** **{settings}** **Settings > Visibility and access controls**.
+  under **Admin Area >** **{settings}** **Settings > Visibility and access controls**.
 - The exports are stored in a temporary [shared directory](../../development/shared_files.md)
   and are deleted every 24 hours by a specific worker.
diff --git a/doc/administration/raketasks/storage.md b/doc/administration/raketasks/storage.md
index 74fd2c2ebb6..a97bff83290 100644
--- a/doc/administration/raketasks/storage.md
+++ b/doc/administration/raketasks/storage.md
@@ -100,7 +100,7 @@ to project IDs 50 to 100 in an Omnibus GitLab installation:
 sudo gitlab-rake gitlab:storage:migrate_to_hashed ID_FROM=50 ID_TO=100
 ```
 
-You can monitor the progress in the **{admin}** **Admin Area > Monitoring > Background Jobs** page.
+You can monitor the progress in the **Admin Area > Monitoring > Background Jobs** page.
 There is a specific queue you can watch to see how long it will take to finish:
 `hashed_storage:hashed_storage_project_migrate`.
 
@@ -150,7 +150,7 @@ to project IDs 50 to 100 in an Omnibus GitLab installation:
 sudo gitlab-rake gitlab:storage:rollback_to_legacy ID_FROM=50 ID_TO=100
 ```
 
-You can monitor the progress in the **{admin}** **Admin Area > Monitoring > Background Jobs** page.
+You can monitor the progress in the **Admin Area > Monitoring > Background Jobs** page.
 On the **Queues** tab, you can watch the `hashed_storage:hashed_storage_project_rollback` queue to see how long the process will take to finish.
 
 After it reaches zero, you can confirm every project has been rolled back by running the commands bellow.
diff --git a/doc/ci/runners/README.md b/doc/ci/runners/README.md
index a9d66aecd6b..1e3cde6af3f 100644
--- a/doc/ci/runners/README.md
+++ b/doc/ci/runners/README.md
@@ -376,7 +376,7 @@ different places.
 To view the IP address of a shared Runner you must have admin access to
 the GitLab instance. To determine this:
 
-1. Visit **{admin}** **Admin Area > Overview > Runners**.
+1. Visit **Admin Area > Overview > Runners**.
 1. Look for the Runner in the table and you should see a column for **IP Address**.
 
 ![shared Runner IP address](img/shared_runner_ip_address.png)
diff --git a/doc/development/img/deployment_pipeline_v13_3.png b/doc/development/img/deployment_pipeline_v13_3.png
new file mode 100644
index 00000000000..77a1853a7ae
--- /dev/null
+++ b/doc/development/img/deployment_pipeline_v13_3.png
diff --git a/doc/development/integrations/jenkins.md b/doc/development/integrations/jenkins.md
index f2bc6532dde..5d3c869d922 100644
--- a/doc/development/integrations/jenkins.md
+++ b/doc/development/integrations/jenkins.md
@@ -16,7 +16,7 @@ brew services start jenkins
 GitLab does not allow requests to localhost or the local network by default. When running Jenkins on your local machine, you need to enable local access.
 
 1. Log into your GitLab instance as an admin.
-1. Go to **{admin}** **Admin Area > Settings > Network**.
+1. Go to **Admin Area > Settings > Network**.
 1. Expand **Outbound requests** and check the following checkboxes:
 
    - **Allow requests to the local network from web hooks and services**
diff --git a/doc/development/multi_version_compatibility.md b/doc/development/multi_version_compatibility.md
index ce6cc6610f4..d9478142cb5 100644
--- a/doc/development/multi_version_compatibility.md
+++ b/doc/development/multi_version_compatibility.md
@@ -20,6 +20,22 @@ but AJAX requests to URLs (like the GraphQL endpoint) won't match the pattern.
 With this canary setup, we'd be in this mixed-versions state for an extended period of time until canary is promoted to
 production and post-deployment migrations run.
 
+Also be aware that during a deployment to production, Web, API, and
+Sidekiq nodes are updated in parallel, but they may finish at
+different times. That means there may be a window of time when the
+application code is not in sync across the whole fleet. Changes that
+cut across Sidekiq, Web, and/or the API may [introduce unexpected
+errors until the deployment is complete](#builds-failing-due-to-varying-deployment-times-across-node-types).
+
+One way to handle this is to use a feature flag that is disabled by
+default. The feature flag can be enabled when the deployment is in a
+consistent state. However, this method of synchronization doesn't
+guarantee that customers with on-premise instances can [upgrade with
+zero downtime](https://docs.gitlab.com/omnibus/update/#zero-downtime-updates)
+since point releases bundle many changes together. Minimizing the time
+between when versions are out of sync across the fleet may help mitigate
+errors caused by upgrades.
+
 ## Examples of previous incidents
 
 ### Some links to issues and MRs were broken
@@ -75,3 +91,37 @@ the new application code, hence QA was successful. Unfortunately, the production
 instance still uses the older code, so it started failing to insert a new release entry.
 
 For more information, see [this issue related to the Releases API](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/64151).
+
+### Builds failing due to varying deployment times across node types
+
+In [one production issue](https://gitlab.com/gitlab-com/gl-infra/production/-/issues/2442),
+CI builds that used the `parallel` keyword and depending on the
+variable `CI_NODE_TOTAL` being an integer failed. This was caused because after a user pushed a commit:
+
+1. New code: Sidekiq created a new pipeline and new build. `build.options[:parallel]` is a `Hash`.
+1. Old code: Runners requested a job from an API node that is running the previous version.
+1. As a result, the [new code](https://gitlab.com/gitlab-org/gitlab/blob/42b82a9a3ac5a96f9152aad6cbc583c42b9fb082/app/models/concerns/ci/contextable.rb#L104)
+was not run on the API server. The runner's request failed because the
+older API server tried return the `CI_NODE_TOTAL` CI variable, but
+instead of sending an integer value (e.g. 9), it sent a serialized
+`Hash` value (`{:number=>9, :total=>9}`).
+
+If you look at the [deployment pipeline](https://ops.gitlab.net/gitlab-com/gl-infra/deployer/-/pipelines/202212),
+you see all nodes were updated in parallel:
+
+![GitLab.com deployment pipeline](img/deployment_pipeline_v13_3.png)
+
+However, even though the updated started around the same time, the completion time varied significantly:
+
+|Node type|Duration (min)|
+|---------|--------------|
+|API      |54            |
+|Sidekiq  |21            |
+|K8S      |8             |
+
+Builds that used the `parallel` keyword and depended on `CI_NODE_TOTAL`
+and `CI_NODE_INDEX` would fail during the time after Sidekiq was
+updated. Since Kubernetes (K8S) also runs Sidekiq pods, the window could
+have been as long as 46 minutes or as short as 33 minutes. Either way,
+having a feature flag to turn on after the deployment finished would
+prevent this from happening.
diff --git a/doc/subscriptions/index.md b/doc/subscriptions/index.md
index 9620cf9acdb..af669117bbd 100644
--- a/doc/subscriptions/index.md
+++ b/doc/subscriptions/index.md
@@ -254,7 +254,7 @@ The following table describes details of your subscription for groups:
 
 To view the status of your self-managed subscription, log in to the self-managed instance and go to the **License** page.
 
-  1. Go to **{admin}** **Admin Area**.
+  1. Go to **Admin Area**.
   1. From the left-hand menu, select **License**.
 
 ## Renew your subscription
@@ -386,8 +386,7 @@ You can view the exact JSON payload in the administration panel. To view the pay
 
 Seat Link is enabled by default.
 
-To disable this feature, go to
-**{admin}** **Admin Area > Settings > Metrics and profiling**, uncheck the **Enable Seat Link** checkbox > **Save changes**.
+To disable this feature, go to **Admin Area > Settings > Metrics and profiling**, uncheck the **Enable Seat Link** checkbox > **Save changes**.
 
 To disable Seat Link in an Omnibus GitLab installation, and prevent it from
 being configured in the future through the administration panel, set the following in
@@ -442,7 +441,7 @@ We recommend following these steps during renewal:
 1. Enter the number of [users over license](#users-over-license) in the second box for the user overage incurred in your previous subscription term.
 
    TIP: **Tip:**
-   You can find the _users over license_ in your instance's **Admin** dashboard by clicking on **{admin}** (**Admin Area**) in the top bar, or going to `/admin`.
+   You can find the _users over license_ in your instance's **Admin** dashboard by clicking on the **Admin Area** in the top bar, or going to `/admin`.
 
    The following table describes details of your admin dashboard and renewal terms:
 
diff --git a/doc/topics/autodevops/index.md b/doc/topics/autodevops/index.md
index 01e61095fe2..3088c57b51a 100644
--- a/doc/topics/autodevops/index.md
+++ b/doc/topics/autodevops/index.md
@@ -130,7 +130,7 @@ any of the following places:
   [groups](../../user/group/clusters/index.md#base-domain)
 - or at the project level as a variable: `KUBE_INGRESS_BASE_DOMAIN`
 - or at the group level as a variable: `KUBE_INGRESS_BASE_DOMAIN`
-- or as an instance-wide fallback in **{admin}** **Admin Area > Settings** under the
+- or as an instance-wide fallback in **Admin Area > Settings** under the
   **Continuous Integration and Delivery** section
 
 The base domain variable `KUBE_INGRESS_BASE_DOMAIN` follows the same order of precedence
@@ -216,7 +216,7 @@ To enable or disable Auto DevOps at the group level:
 Even when disabled at the instance level, group owners and project maintainers can still enable
 Auto DevOps at the group and project level, respectively.
 
-1. Go to **{admin}** **Admin Area > Settings > Continuous Integration and Deployment**.
+1. Go to **Admin Area > Settings > Continuous Integration and Deployment**.
 1. Select **Default to Auto DevOps pipeline for all projects** to enable it.
 1. (Optional) You can set up the Auto DevOps [base domain](#auto-devops-base-domain),
    for Auto Deploy and Auto Review Apps to use.
diff --git a/doc/user/admin_area/abuse_reports.md b/doc/user/admin_area/abuse_reports.md
index ed68b8b7432..0283f1a9eff 100644
--- a/doc/user/admin_area/abuse_reports.md
+++ b/doc/user/admin_area/abuse_reports.md
@@ -16,7 +16,7 @@ reports in the Admin Area.
 
 To receive notifications of new abuse reports by e-mail, follow these steps:
 
-1. Select **{admin}** **Admin Area > Settings >  Reporting**.
+1. Select **Admin Area > Settings >  Reporting**.
 1. Expand the **Abuse reports** section.
 1. Provide an email address.
 
diff --git a/doc/user/admin_area/index.md b/doc/user/admin_area/index.md
index e63d0c7c882..f1a95e2134d 100644
--- a/doc/user/admin_area/index.md
+++ b/doc/user/admin_area/index.md
@@ -65,7 +65,7 @@ The following topics document the **{overview}** **Overview** section of the Adm
 
 You can administer all projects in the GitLab instance from the Admin Area's Projects page.
 
-To access the Projects page, go to **{admin}** **Admin Area >** **{overview}** **Overview > Projects**.
+To access the Projects page, go to **Admin Area >** **{overview}** **Overview > Projects**.
 
 Click the **All**, **Private**, **Internal**, or **Public** tab to list only projects of that
 criteria.
@@ -105,7 +105,7 @@ You can combine the filter options. For example, to list only public projects wi
 
 You can administer all users in the GitLab instance from the Admin Area's Users page.
 
-To access the Users page, go to **{admin}** **Admin Area >** **{overview}** **Overview > Users**.
+To access the Users page, go to **Admin Area >** **{overview}** **Overview > Users**.
 
 To list users matching a specific criteria, click on one of the following tabs on the **Users** page:
 
@@ -157,7 +157,7 @@ reflected in the statistics.
 
 You can administer all groups in the GitLab instance from the Admin Area's Groups page.
 
-To access the Groups page, go to **{admin}** **Admin Area >** **{overview}** **Overview > Groups**.
+To access the Groups page, go to **Admin Area >** **{overview}** **Overview > Groups**.
 
 For each group, the page displays their name, description, size, number of projects in the group,
 number of members, and whether the group is private, internal, or public. To edit a group, click
@@ -176,7 +176,7 @@ To [Create a new group](../group/index.md#create-a-new-group) click **New group*
 
 You can administer all jobs in the GitLab instance from the Admin Area's Jobs page.
 
-To access the Jobs page, go to **{admin}** **Admin Area >** **{overview}** **Overview > Jobs**.
+To access the Jobs page, go to **Admin Area >** **{overview}** **Overview > Jobs**.
 
 All jobs are listed, in descending order of job ID.
 
@@ -201,7 +201,7 @@ For each job, the following details are listed:
 You can administer all Runners in the GitLab instance from the Admin Area's **Runners** page. See
 [GitLab Runner](https://docs.gitlab.com/runner/) for more information on Runner itself.
 
-To access the **Runners** page, go to **{admin}** **Admin Area >** **{overview}** **Overview > Runners**.
+To access the **Runners** page, go to **Admin Area >** **{overview}** **Overview > Runners**.
 
 The **Runners** page features:
 
@@ -247,7 +247,7 @@ You can also edit, pause, or remove each Runner.
 You can list all Gitaly servers in the GitLab instance from the Admin Area's **Gitaly Servers**
 page. For more details, see [Gitaly](../../administration/gitaly/index.md).
 
-To access the **Gitaly Servers** page, go to **{admin}** **Admin Area >** **{overview}** **Overview > Gitaly Servers**.
+To access the **Gitaly Servers** page, go to **Admin Area >** **{overview}** **Overview > Gitaly Servers**.
 
 For each Gitaly server, the following details are listed:
 
diff --git a/doc/user/admin_area/merge_requests_approvals.md b/doc/user/admin_area/merge_requests_approvals.md
index 6d9d634ce14..8f51c03e105 100644
--- a/doc/user/admin_area/merge_requests_approvals.md
+++ b/doc/user/admin_area/merge_requests_approvals.md
@@ -15,7 +15,7 @@ if they are enabled at an instance level.
 
 To enable merge request approval rules for an instance:
 
-1. Navigate to **{admin}** **Admin Area >** **{push-rules}** **Push Rules** and expand **Merge
+1. Navigate to **Admin Area >** **{push-rules}** **Push Rules** and expand **Merge
    requests approvals**.
 1. Set the required rule.
 1. Click **Save changes**.
diff --git a/doc/user/admin_area/settings/index.md b/doc/user/admin_area/settings/index.md
index c28e34b1a1a..8728ec9a112 100644
--- a/doc/user/admin_area/settings/index.md
+++ b/doc/user/admin_area/settings/index.md
@@ -4,7 +4,7 @@ type: index
 
 # Admin Area settings **(CORE ONLY)**
 
-As an administrator of a GitLab self-managed instance, you can manage the behavior of your deployment. To do so, select **{admin}** **Admin Area > Settings**.
+As an administrator of a GitLab self-managed instance, you can manage the behavior of your deployment. To do so, select **Admin Area > Settings**.
 
 The admin area is not accessible on GitLab.com, and settings can only be changed by the
 GitLab.com administrators. See the [GitLab.com settings](../../gitlab_com/index.md)
@@ -12,8 +12,7 @@ documentation for all current settings and limits on the GitLab.com instance.
 
 ## General
 
-Access the default page for admin area settings by navigating to
-**{admin}** **Admin Area > Settings > General**:
+Access the default page for admin area settings by navigating to **Admin Area > Settings > General**:
 
 | Option | Description |
 | ------ | ----------- |
@@ -96,7 +95,7 @@ Access the default page for admin area settings by navigating to
 
 | Option | Description |
 | ------ | ----------- |
-| Geo    | Geo allows you to replicate your GitLab instance to other geographical locations. Redirects to **{admin}** **Admin Area >** **{location-dot}** **Geo >** **{settings}** **Settings**, and will no longer be available at **{admin}** **Admin Area >** **{settings}** **Settings >** **{location-dot}** **Geo** in [GitLab 13.0](https://gitlab.com/gitlab-org/gitlab/-/issues/36896). |
+| Geo    | Geo allows you to replicate your GitLab instance to other geographical locations. Redirects to **Admin Area >** **{location-dot}** **Geo >** **{settings}** **Settings**, and will no longer be available at **Admin Area >** **{settings}** **Settings >** **{location-dot}** **Geo** in [GitLab 13.0](https://gitlab.com/gitlab-org/gitlab/-/issues/36896). |
 
 ## Preferences
 
diff --git a/doc/user/group/settings/import_export.md b/doc/user/group/settings/import_export.md
index cca918d44f3..b89fcf2704d 100644
--- a/doc/user/group/settings/import_export.md
+++ b/doc/user/group/settings/import_export.md
@@ -21,7 +21,7 @@ See also:
 
 To enable GitLab import/export:
 
-1. Navigate to **{admin}** **Admin Area >** **{settings}** **Settings > Visibility and access controls**.
+1. Navigate to **Admin Area >** **{settings}** **Settings > Visibility and access controls**.
 1. Scroll to **Import sources**
 1. Enable desired **Import sources**
 
diff --git a/doc/user/packages/maven_repository/index.md b/doc/user/packages/maven_repository/index.md
index 0098ab1bbcb..4669a998d25 100644
--- a/doc/user/packages/maven_repository/index.md
+++ b/doc/user/packages/maven_repository/index.md
@@ -829,10 +829,25 @@ You can play around with the regex and try your version strings on [this regular
 
 ## Troubleshooting
 
-### Useful Maven command line options
+### Review network trace logs
 
-There's some [maven command line options](https://maven.apache.org/ref/current/maven-embedder/cli.html)
-which maybe useful when doing tasks with GitLab CI/CD.
+If you are having issues with the Maven Repository, you may want to review network trace logs.
+
+For example, try to run `mvn deploy` locally with a PAT token and use these options:
+
+```shell
+mvn deploy \
+-Dorg.slf4j.simpleLogger.log.org.apache.maven.wagon.providers.http.httpclient=trace \
+-Dorg.slf4j.simpleLogger.log.org.apache.maven.wagon.providers.http.httpclient.wire=trace
+```
+
+CAUTION: **Caution:**
+When you set these options, all network requests are logged and a large amount of output is generated.
+
+### Useful Maven command-line options
+
+There are some [Maven command-line options](https://maven.apache.org/ref/current/maven-embedder/cli.html)
+that may be useful when performing tasks with GitLab CI/CD.
 
 - File transfer progress can make the CI logs hard to read.
   Option `-ntp,--no-transfer-progress` was added in
diff --git a/doc/user/project/clusters/add_eks_clusters.md b/doc/user/project/clusters/add_eks_clusters.md
index f0b6fe81c18..241bf59dcd2 100644
--- a/doc/user/project/clusters/add_eks_clusters.md
+++ b/doc/user/project/clusters/add_eks_clusters.md
@@ -58,7 +58,7 @@ To create and add a new Kubernetes cluster to your project, group, or instance:
 1. Navigate to your:
    - Project's **{cloud-gear}** **Operations > Kubernetes** page, for a project-level cluster.
    - Group's **{cloud-gear}** **Kubernetes** page, for a group-level cluster.
-   - **{admin}** **Admin Area >** **{cloud-gear}** **Kubernetes**, for an instance-level cluster.
+   - **Admin Area >** **{cloud-gear}** **Kubernetes**, for an instance-level cluster.
 1. Click **Add Kubernetes cluster**.
 1. Under the **Create new cluster** tab, click **Amazon EKS**. You will be provided with an
    `Account ID` and `External ID` to use in the next step.
diff --git a/doc/user/project/clusters/add_gke_clusters.md b/doc/user/project/clusters/add_gke_clusters.md
index 2746076befe..e9176badf38 100644
--- a/doc/user/project/clusters/add_gke_clusters.md
+++ b/doc/user/project/clusters/add_gke_clusters.md
@@ -48,7 +48,7 @@ To create and add a new Kubernetes cluster to your project, group, or instance:
 1. Navigate to your:
    - Project's **{cloud-gear}** **Operations > Kubernetes** page, for a project-level cluster.
    - Group's **{cloud-gear}** **Kubernetes** page, for a group-level cluster.
-   - **{admin}** **Admin Area >** **{cloud-gear}** **Kubernetes** page, for an instance-level cluster.
+   - **Admin Area >** **{cloud-gear}** **Kubernetes** page, for an instance-level cluster.
 1. Click **Add Kubernetes cluster**.
 1. Under the **Create new cluster** tab, click **Google GKE**.
 1. Connect your Google account if you haven't done already by clicking the
diff --git a/doc/user/project/clusters/add_remove_clusters.md b/doc/user/project/clusters/add_remove_clusters.md
index 65f1c59f4ca..e62d85df2e6 100644
--- a/doc/user/project/clusters/add_remove_clusters.md
+++ b/doc/user/project/clusters/add_remove_clusters.md
@@ -142,7 +142,7 @@ Amazon Elastic Kubernetes Service (EKS) at the project, group, or instance level
 1. Navigate to your:
    - Project's **{cloud-gear}** **Operations > Kubernetes** page, for a project-level cluster.
    - Group's **{cloud-gear}** **Kubernetes** page, for a group-level cluster.
-   - **{admin}** **Admin Area >** **{cloud-gear}** **Kubernetes** page, for an instance-level cluster.
+   - **Admin Area >** **{cloud-gear}** **Kubernetes** page, for an instance-level cluster.
 1. Click **Add Kubernetes cluster**.
 1. Click the **Create new cluster** tab.
 1. Click either **Amazon EKS** or **Google GKE**, and follow the instructions for your desired service:
@@ -164,7 +164,7 @@ To add a Kubernetes cluster to your project, group, or instance:
 1. Navigate to your:
    1. Project's **{cloud-gear}** **Operations > Kubernetes** page, for a project-level cluster.
    1. Group's **{cloud-gear}** **Kubernetes** page, for a group-level cluster.
-   1. **{admin}** **Admin Area >** **{cloud-gear}** **Kubernetes** page, for an instance-level cluster.
+   1. **Admin Area >** **{cloud-gear}** **Kubernetes** page, for an instance-level cluster.
 1. Click **Add Kubernetes cluster**.
 1. Click the **Add existing cluster** tab and fill in the details:
    1. **Kubernetes cluster name** (required) - The name you wish to give the cluster.
@@ -331,7 +331,7 @@ a new cluster or added an existing one. To disable Kubernetes cluster integratio
 1. Navigate to your:
    - Project's **{cloud-gear}** **Operations > Kubernetes** page, for a project-level cluster.
    - Group's **{cloud-gear}** **Kubernetes** page, for a group-level cluster.
-   - **{admin}** **Admin Area >** **{cloud-gear}** **Kubernetes** page, for an instance-level cluster.
+   - **Admin Area >** **{cloud-gear}** **Kubernetes** page, for an instance-level cluster.
 1. Click on the name of the cluster.
 1. Click the **GitLab Integration** toggle.
 1. Click **Save changes**.
diff --git a/doc/user/project/deploy_keys/index.md b/doc/user/project/deploy_keys/index.md
index 32d3eab5e62..81c9008c5b3 100644
--- a/doc/user/project/deploy_keys/index.md
+++ b/doc/user/project/deploy_keys/index.md
@@ -121,7 +121,7 @@ repositories to secure, shared services, such as CI/CD.
 
 Instance administrators can add public deploy keys:
 
-1. Go to **Admin Area** (**{admin}**) **> Deploy Keys**.
+1. Go to **Admin Area > Deploy Keys**.
 1. Click on **New deploy key**.
 
    Make sure your new key has a meaningful title, as it is the primary way for project
diff --git a/doc/user/project/import/jira.md b/doc/user/project/import/jira.md
index 482e632baa2..7f179865f4f 100644
--- a/doc/user/project/import/jira.md
+++ b/doc/user/project/import/jira.md
@@ -77,10 +77,9 @@ Importing large projects may take several minutes depending on the size of the i
 
    In the **Jira-GitLab user mapping template** section, the table shows to which GitLab users your Jira
    users will be mapped.
-   If it wasn't possible to match a Jira user with a GitLab user, the dropdown defaults to the user
-   conducting the import.
+   When the form appears, the dropdown defaults to the user conducting the import.
 
-1. To change any of the suggested mappings, click the dropdown in the **GitLab username** column and
+1. To change any of the mappings, click the dropdown in the **GitLab username** column and
    select the user you want to map to each Jira user.
 
    The dropdown may not show all the users, so use the search bar to find a specific
diff --git a/doc/user/project/repository/branches/index.md b/doc/user/project/repository/branches/index.md
index 211648df126..54979d1c4ce 100644
--- a/doc/user/project/repository/branches/index.md
+++ b/doc/user/project/repository/branches/index.md
@@ -66,7 +66,7 @@ By default, when you create a new project in GitLab, the initial branch is calle
 For self-managed instances, a GitLab administrator can customize the initial branch name to something
 else. This way, every new project created from then on will start from the custom branch name rather than `master`. To do so:
 
-1. Go to the **{admin}** **Admin Area > Settings > Repository** and expand **Default initial
+1. Go to the **Admin Area > Settings > Repository** and expand **Default initial
    branch name**.
 1. Change the default initial branch to a custom name of your choice.
 1. **Save Changes**.
diff --git a/doc/user/project/settings/import_export.md b/doc/user/project/settings/import_export.md
index 76952b3089a..3088acc4ad4 100644
--- a/doc/user/project/settings/import_export.md
+++ b/doc/user/project/settings/import_export.md
@@ -24,7 +24,7 @@ See also:
 
 To set up a project import/export:
 
-  1. Navigate to **{admin}** **Admin Area >** **{settings}** **Settings > Visibility and access controls**.
+  1. Navigate to **Admin Area >** **{settings}** **Settings > Visibility and access controls**.
   1. Scroll to **Import sources**
   1. Enable desired **Import sources**
 
diff --git a/locale/gitlab.pot b/locale/gitlab.pot
index 8cd3b49a0d4..5940ce21fb4 100644
--- a/locale/gitlab.pot
+++ b/locale/gitlab.pot
@@ -13333,7 +13333,7 @@ msgstr ""
 msgid "Jira service not configured."
 msgstr ""
 
-msgid "Jira users have been matched with similar GitLab users. This can be overwritten by selecting a GitLab user from the dropdown in the \"GitLab username\" column. If it wasn't possible to match a Jira user with a GitLab user, the dropdown defaults to the user conducting the import."
+msgid "Jira users have been imported from the configured Jira instance. They can be mapped by selecting a GitLab user from the dropdown in the \"GitLab username\" column. When the form appears, the dropdown defaults to the user conducting the import."
 msgstr ""
 
 msgid "Jira-GitLab user mapping template"
@@ -27477,13 +27477,16 @@ msgstr ""
 msgid "You have been granted %{access_level} access to the %{source_name} %{source_type}."
 msgstr ""
 
-msgid "You have been granted %{member_human_access} access to %{label}."
+msgid "You have been granted %{member_human_access} access to %{title} %{name}."
+msgstr ""
+
+msgid "You have been invited"
 msgstr ""
 
 msgid "You have been unsubscribed from this thread."
 msgstr ""
 
-msgid "You have declined the invitation to join %{label}."
+msgid "You have declined the invitation to join %{title} %{name}."
 msgstr ""
 
 msgid "You have imported from this project %{numberOfPreviousImports} times before. Each new import will create duplicate issues."
@@ -27953,6 +27956,9 @@ msgstr ""
 msgid "archived:"
 msgstr ""
 
+msgid "as %{role}."
+msgstr ""
+
 msgid "assign yourself"
 msgstr ""
 
@@ -28874,10 +28880,10 @@ msgstr ""
 msgid "mrWidget|You can delete the source branch now"
 msgstr ""
 
-msgid "mrWidget|You can merge this merge request manually using the"
+msgid "mrWidget|You can merge after removing denied licenses"
 msgstr ""
 
-msgid "mrWidget|You can only merge once the denied license is removed"
+msgid "mrWidget|You can merge this merge request manually using the"
 msgstr ""
 
 msgid "mrWidget|Your password"
@@ -29232,6 +29238,9 @@ msgstr ""
 msgid "to help your contributors communicate effectively!"
 msgstr ""
 
+msgid "to join %{source_name}"
+msgstr ""
+
 msgid "to list"
 msgstr ""
 
diff --git a/spec/controllers/invites_controller_spec.rb b/spec/controllers/invites_controller_spec.rb
index a9e4073780d..2b222331b55 100644
--- a/spec/controllers/invites_controller_spec.rb
+++ b/spec/controllers/invites_controller_spec.rb
@@ -34,25 +34,4 @@ RSpec.describe InvitesController do
       expect(flash[:notice]).to be_nil
     end
   end
-
-  describe 'POST #accept' do
-    it 'accepts user' do
-      expect do
-        post :accept, params: { id: token }
-      end.to change { project_members.include?(user) }.from(false).to(true)
-
-      expect(response).to have_gitlab_http_status(:found)
-      expect(flash[:notice]).to include 'You have been granted'
-    end
-  end
-
-  describe 'GET #decline' do
-    it 'declines user' do
-      get :decline, params: { id: token }
-
-      expect { member.reload }.to raise_error ActiveRecord::RecordNotFound
-      expect(response).to have_gitlab_http_status(:found)
-      expect(flash[:notice]).to include 'You have declined the invitation to join'
-    end
-  end
 end
diff --git a/spec/features/invites_spec.rb b/spec/features/invites_spec.rb
index d91fae5cdfd..c0f453206a8 100644
--- a/spec/features/invites_spec.rb
+++ b/spec/features/invites_spec.rb
@@ -63,6 +63,8 @@ RSpec.describe 'Invites', :aggregate_failures do
 
     it 'shows message user already a member' do
       visit invite_path(group_invite.raw_invite_token)
+
+      expect(page).to have_link(owner.name, href: user_url(owner))
       expect(page).to have_content('However, you are already a member of this group.')
     end
   end
@@ -197,8 +199,10 @@ RSpec.describe 'Invites', :aggregate_failures do
 
         it 'declines application and redirects to dashboard' do
           page.click_link 'Decline'
+
           expect(current_path).to eq(dashboard_projects_path)
           expect(page).to have_content('You have declined the invitation to join group Owned.')
+          expect { group_invite.reload }.to raise_error ActiveRecord::RecordNotFound
         end
       end
 
@@ -209,7 +213,9 @@ RSpec.describe 'Invites', :aggregate_failures do
 
         it 'declines application and redirects to sign in page' do
           expect(current_path).to eq(new_user_session_path)
+
           expect(page).to have_content('You have declined the invitation to join group Owned.')
+          expect { group_invite.reload }.to raise_error ActiveRecord::RecordNotFound
         end
       end
     end
@@ -223,9 +229,13 @@ RSpec.describe 'Invites', :aggregate_failures do
       end
 
       it 'grants access and redirects to group page' do
+        expect(group.users.include?(user)).to be false
+
         page.click_link 'Accept invitation'
+
         expect(current_path).to eq(group_path(group))
         expect(page).to have_content('You have been granted Owner access to group Owned.')
+        expect(group.users.include?(user)).to be true
       end
     end
   end
diff --git a/spec/frontend/incidents/components/incidents_list_spec.js b/spec/frontend/incidents/components/incidents_list_spec.js
index d5293aed493..0d7daf08272 100644
--- a/spec/frontend/incidents/components/incidents_list_spec.js
+++ b/spec/frontend/incidents/components/incidents_list_spec.js
@@ -1,6 +1,6 @@
 import { mount } from '@vue/test-utils';
-import { visitUrl, joinPaths } from '~/lib/utils/url_utility';
 import { GlAlert, GlLoadingIcon, GlTable, GlAvatar, GlSearchBoxByType } from '@gitlab/ui';
+import { visitUrl, joinPaths } from '~/lib/utils/url_utility';
 import IncidentsList from '~/incidents/components/incidents_list.vue';
 import TimeAgoTooltip from '~/vue_shared/components/time_ago_tooltip.vue';
 import { I18N } from '~/incidents/constants';
@@ -25,6 +25,7 @@ describe('Incidents List', () => {
   const findAssingees = () => wrapper.findAll('[data-testid="incident-assignees"]');
   const findCreateIncidentBtn = () => wrapper.find('[data-testid="createIncidentBtn"]');
   const findSearch = () => wrapper.find(GlSearchBoxByType);
+  const findClosedIcon = () => wrapper.findAll("[data-testid='incident-closed']");
 
   function mountComponent({ data = { incidents: [] }, loading = false }) {
     wrapper = mount(IncidentsList, {
@@ -127,6 +128,12 @@ describe('Incidents List', () => {
           .trigger('click');
         expect(visitUrl).toHaveBeenCalledWith(joinPaths(`/project/isssues/`, mockIncidents[0].iid));
       });
+
+      it('renders a closed icon for closed incidents', () => {
+        expect(findClosedIcon().length).toBe(
+          mockIncidents.filter(({ state }) => state === 'closed').length,
+        );
+      });
     });
   });
 
diff --git a/spec/frontend/incidents/mocks/incidents.json b/spec/frontend/incidents/mocks/incidents.json
index 734aba190ba..4eab709e53f 100644
--- a/spec/frontend/incidents/mocks/incidents.json
+++ b/spec/frontend/incidents/mocks/incidents.json
@@ -3,7 +3,8 @@
     "iid": "15",
     "title": "New: Incident",
     "createdAt": "2020-06-03T15:46:08Z",
-    "assignees": {}
+    "assignees": {},
+    "state": "opened"
   },
   {
     "iid": "14",
@@ -18,18 +19,21 @@
           "webUrl": "https://invalid"
         }
       ]
-    }
+    },
+    "state": "opened"
   },
   {
     "iid": "13",
     "title": "Create issue3",
     "createdAt": "2020-05-19T08:53:55Z",
-    "assignees": {}
+    "assignees": {},
+    "state": "closed"
   },
   {
     "iid": "12",
     "title": "Create issue2",
     "createdAt": "2020-05-18T17:13:35Z",
-    "assignees": {}
+    "assignees": {},
+    "state": "closed"
   }
 ]
diff --git a/spec/frontend/jira_import/components/jira_import_form_spec.js b/spec/frontend/jira_import/components/jira_import_form_spec.js
index 12d161edf72..42773934945 100644
--- a/spec/frontend/jira_import/components/jira_import_form_spec.js
+++ b/spec/frontend/jira_import/components/jira_import_form_spec.js
@@ -103,7 +103,7 @@ describe('JiraImportForm', () => {
 
     it('shows information to the user', () => {
       expect(wrapper.find('p').text()).toBe(
-        'Jira users have been matched with similar GitLab users. This can be overwritten by selecting a GitLab user from the dropdown in the "GitLab username" column. If it wasn\'t possible to match a Jira user with a GitLab user, the dropdown defaults to the user conducting the import.',
+        'Jira users have been imported from the configured Jira instance. They can be mapped by selecting a GitLab user from the dropdown in the "GitLab username" column. When the form appears, the dropdown defaults to the user conducting the import.',
       );
     });
   });
diff --git a/spec/requests/api/import_bitbucket_server_spec.rb b/spec/requests/api/import_bitbucket_server_spec.rb
index 5828dab3080..dac139064da 100644
--- a/spec/requests/api/import_bitbucket_server_spec.rb
+++ b/spec/requests/api/import_bitbucket_server_spec.rb
@@ -96,7 +96,7 @@ RSpec.describe API::ImportBitbucketServer do
         Grape::Endpoint.before_each nil
       end
 
-      it 'returns 400 response due to a blcoked URL' do
+      it 'returns 400 response due to a blocked URL' do
         allow(Gitlab::BitbucketServerImport::ProjectCreator)
         .to receive(:new).with(project_key, repo_slug, anything, project.name, user.namespace, user, anything)
         .and_return(double(execute: project))