Add latest changes from gitlab-org/gitlab@master

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 }">

app/assets/javascripts/incidents/graphql/queries/get_incidents.query.graphql

@@ -10,6 +10,7 @@ query getIncidents(
         iid
         title
         createdAt
+        state
         labels {
           nodes {
             title

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>

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

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"

changelogs/unreleased/229401-close-icon.yml

+---
+title: Add closed issue icon to incidents list for closed incidents
+merge_request: 37949
+author:
+type: changed

db/fixtures/development/28_integrations.rb

+# 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

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)

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

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.
 

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.
 

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.

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.

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.
 

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

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.

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.

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`.

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
 

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**.

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

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.
 

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)
 

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.

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.

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)

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**

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.

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:
 

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.

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.
 

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:
 

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**.

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
 

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**
 

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

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.

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

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**.

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

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

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**.

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**
 

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 ""
 

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

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

spec/frontend/incidents/components/incidents_list_spec.js

 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,
+        );
+      });
     });
   });
 

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"
   }
 ]

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.',
       );
     });
   });

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))