Add latest changes from gitlab-org/gitlab@master

19 files changed, 244 insertions, 91 deletions

diff --git a/doc/administration/audit_events.md b/doc/administration/audit_events.md
index bd8699c2c1f..341a14e5e73 100644
--- a/doc/administration/audit_events.md
+++ b/doc/administration/audit_events.md
@@ -49,7 +49,7 @@ To view a project's audit events:
 Project events can also be accessed using the [Project Audit Events API](../api/audit_events.md#project-audit-events).
 Project event queries are limited to a maximum of 30 days.
 
-### View instance audit events **(PREMIUM SELF)**
+## View instance audit events **(PREMIUM SELF)**
 
 You can view audit events from user actions across an entire GitLab instance.
 
@@ -58,6 +58,47 @@ To view instance audit events:
 1. On the top bar, select **Main menu > Admin**.
 1. On the left sidebar, select **Monitoring > Audit Events**.
 
+### Export to CSV
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/1449) in GitLab 13.4.
+> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/285441) in GitLab 13.7.
+
+You can export the current view (including filters) of your instance audit events as a CSV file. To export the instance
+audit events to CSV:
+
+1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, select **Monitoring > Audit Events**.
+1. Select the available search [filters](#filter-audit-events).
+1. Select **Export as CSV**.
+
+The exported file:
+
+- Is sorted by `created_at` in ascending order.
+- Is limited to a maximum of 100 000 events. The remaining records are truncated when this limit is reached.
+
+Data is encoded with:
+
+- Comma as the column delimiter.
+- `"` to quote fields if necessary.
+- New lines separate rows.
+
+The first row contains the headers, which are listed in the following table along with a description of the values:
+
+| Column               | Description                                        |
+|:---------------------|:---------------------------------------------------|
+| **ID**               | Audit event `id`.                                  |
+| **Author ID**        | ID of the author.                                  |
+| **Author Name**      | Full name of the author.                           |
+| **Entity ID**        | ID of the scope.                                   |
+| **Entity Type**      | Type of the scope (`Project`, `Group`, or `User`). |
+| **Entity Path**      | Path of the scope.                                 |
+| **Target ID**        | ID of the target.                                  |
+| **Target Type**      | Type of the target.                                |
+| **Target Details**   | Details of the target.                             |
+| **Action**           | Description of the action.                         |
+| **IP Address**       | IP address of the author who performed the action. |
+| **Created At (UTC)** | Formatted as `YYYY-MM-DD HH:MM:SS`.                |
+
 ## Time zones
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/242014) in GitLab 15.7, GitLab UI shows dates and times in the user's local time zone instead of UTC.
@@ -70,25 +111,38 @@ The time zone used for audit events depends on where you view them:
 - In `audit_json.log`, UTC is used.
 - In CSV exports, UTC is used.
 
-## List of events
+## Filter audit events
 
-You can view different events depending on the version of GitLab you have.
+From audit events pages, different filters are available depending on the page you're on.
+
+| Audit event page | Available filter                                                                                                       |
+|:-----------------|:-----------------------------------------------------------------------------------------------------------------------|
+| Project          | User (member of the project) who performed the action.                                                                 |
+| Group            | User (member of the group) who performed the action.                                                                   |
+| Instance         | Group, project, or user.                                                                                               |
+| All              | Date range buttons and pickers (maximum range of 31 days). Default is from the first day of the month to today's date. |
+
+## User impersonation
 
-### Impersonation data
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/536) in GitLab 13.0.
+> - Impersonation session events included in group audit events in GitLab 14.8.
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/536) in GitLab 13.0.
+When a user is [impersonated](../user/admin_area/index.md#user-impersonation), their actions are logged as audit events
+with additional details:
 
-When a user is being [impersonated](../user/admin_area/index.md#user-impersonation), their actions are logged as audit events as usual, with two additional details:
+- Audit events include information about the impersonating administrator. These audit events are visible in audit event
+  pages depending on the audit event type (group, project, or user).
+- Extra audit events are recorded for the start and end of the administrator's impersonation session. These audit events
+  are visible as:
+  - Instance audit events.
+  - Group audit events for all groups the user belongs to. For performance reasons, group audit events are limited to
+    the oldest 20 groups you belong to.
 
-1. Usual audit events include information about the impersonating administrator. These audit events are visible in their
-   respective audit event pages depending on their type (group, project, or user).
-1. Extra audit events are recorded for the start and stop of the administrator's impersonation session. These audit events
-   are visible in the:
-   - Instance audit events.
-   - Group audit events for all groups the user belongs to (GitLab 14.8 and later). For performance reasons, group audit
-     events are limited to the oldest 20 groups to which you belong.
+![Audit event with impersonated user](img/impersonated_audit_events_v15_7.png)
 
-![audit events](img/impersonated_audit_events_v13_8.png)
+## Available audit events
+
+You can view different events depending on the version of GitLab you have.
 
 ### Group events
 
@@ -276,61 +330,3 @@ The repositories push events feature was:
 
 - [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/337993) in GitLab 14.3.
 - [Removed](https://gitlab.com/gitlab-org/gitlab/-/issues/337993) in GitLab 15.0.
-
-## Search
-
-The search filters you can see depends on which audit level you are at.
-
-| Filter | Available options |
-| ------ | ----------------- |
-| Scope (Project level) | A specific user who performed the action. |
-| Scope (Group level) | A specific user (in a group) who performed the action. |
-| Scope (Instance level) | A specific group, project, or user that the action was scoped to. |
-| Date range | Either via the date range buttons or pickers (maximum range of 31 days). Default is from the first day of the month to today's date. |
-
-![audit events](img/audit_events_v14_5.png)
-
-## Export to CSV **(PREMIUM SELF)**
-
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/1449) in GitLab 13.4.
-> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/285441) in GitLab 13.7.
-
-Export to CSV allows customers to export the current filter view of your audit events as a
-CSV file, which stores tabular data in plain text. The data provides a comprehensive view with respect to
-audit events.
-
-To export the audit events to CSV:
-
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Monitoring > Audit Events**.
-1. Select the available search [filters](#search).
-1. Select **Export as CSV**.
-
-### Sort
-
-Exported events are always sorted by `created_at` in ascending order.
-
-### Format
-
-Data is encoded with a comma as the column delimiter, with `"` used to quote fields if needed, and newlines to separate rows.
-The first row contains the headers, which are listed in the following table along with a description of the values:
-
-| Column  | Description |
-|---------|-------------|
-| ID | Audit event `id` |
-| Author ID | ID of the author |
-| Author Name | Full name of the author |
-| Entity ID | ID of the scope |
-| Entity Type | Type of the scope (`Project`/`Group`/`User`) |
-| Entity Path | Path of the scope |
-| Target ID | ID of the target |
-| Target Type | Type of the target |
-| Target Details | Details of the target |
-| Action | Description of the action |
-| IP Address | IP address of the author who performed the action |
-| Created At (UTC) | Date (in ISO 8601 format) that the audit event was created. |
-
-### Limitation
-
-The audit events CSV file is limited to a maximum of `100,000` events.
-The remaining records are truncated when this limit is reached.
diff --git a/doc/administration/gitaly/monitoring.md b/doc/administration/gitaly/monitoring.md
index 8d4f30c7c20..9024da269ca 100644
--- a/doc/administration/gitaly/monitoring.md
+++ b/doc/administration/gitaly/monitoring.md
@@ -49,7 +49,7 @@ the Gitaly logs and Prometheus:
 You can observe the status of [control groups (cgroups)](configure_gitaly.md#control-groups) using Prometheus:
 
 - `gitaly_cgroups_reclaim_attempts_total`, a gauge for the total number of times
-   there has been a memory relcaim attempt. This number resets each time a server is
+   there has been a memory reclaim attempt. This number resets each time a server is
    restarted.
 - `gitaly_cgroups_cpu_usage`, a gauge that measures CPU usage per cgroup.
 - `gitaly_cgroup_procs_total`, a gauge that measures the total number of
diff --git a/doc/administration/housekeeping.md b/doc/administration/housekeeping.md
index 2d3e937e047..95b3064c4d6 100644
--- a/doc/administration/housekeeping.md
+++ b/doc/administration/housekeeping.md
@@ -208,7 +208,7 @@ of a repository. When creating the first fork, we:
 
 1. Create an object pool repository that contains all objects of the repository
    that is about to be forked.
-1. Link the repository to this new object pool via Git's altenates mechanism.
+1. Link the repository to this new object pool via Git's alternates mechanism.
 1. Repack the repository so that it uses objects from the object pool. It thus
    can drop its own copy of the objects.
 
diff --git a/doc/administration/img/audit_events_v14_5.png b/doc/administration/img/audit_events_v14_5.png
deleted file mode 100644
index 57190463d05..00000000000
--- a/doc/administration/img/audit_events_v14_5.png
+++ /dev/null
diff --git a/doc/administration/img/impersonated_audit_events_v13_8.png b/doc/administration/img/impersonated_audit_events_v13_8.png
deleted file mode 100644
index 0a8548d515d..00000000000
--- a/doc/administration/img/impersonated_audit_events_v13_8.png
+++ /dev/null
diff --git a/doc/administration/img/impersonated_audit_events_v15_7.png b/doc/administration/img/impersonated_audit_events_v15_7.png
new file mode 100644
index 00000000000..3e64af8e230
--- /dev/null
+++ b/doc/administration/img/impersonated_audit_events_v15_7.png
diff --git a/doc/administration/sidekiq/processing_specific_job_classes.md b/doc/administration/sidekiq/processing_specific_job_classes.md
index 18ffc8a8865..76ac17ce43c 100644
--- a/doc/administration/sidekiq/processing_specific_job_classes.md
+++ b/doc/administration/sidekiq/processing_specific_job_classes.md
@@ -158,6 +158,97 @@ nodes. In this example, we exclude all import-related jobs from a Sidekiq node.
    sudo gitlab-ctl reconfigure
    ```
 
+### Migrating from queue selectors to routing rules
+
+We recommend GitLab deployments add more Sidekiq processes listening to all queues, as in the
+[Reference Architectures](../reference_architectures/index.md). For very large-scale deployments, we recommend
+[routing rules](#routing-rules) instead of [queue selectors](#queue-selectors). We use routing rules on GitLab.com as
+it helps to lower the load on Redis.
+
+To migrate from queue selectors to routing rules:
+
+1. Open `/etc/gitlab/gitlab.rb`.
+1. Set `sidekiq['queue_selector']` to `false`.
+1. Take all queue `selector`s in the `sidekiq['queue_groups']`.
+1. Give each `selector` a `queue_name` and put them in `[selector, queue_name]` format.
+1. Replace `sidekiq['routing_rules']` with an array of `[selector, queue_name]` entries.
+1. Add a wildcard match of `['*', 'default']` as the last entry in `sidekiq['routing_rules']`. This "catchall" queue has
+   to be named as `default`.
+1. Replace `sidekiq['queue_groups']` with `queue_name`s.
+1. Add at least one `default` queue to the `sidekiq['queue_groups']`.
+1. Save the file and reconfigure GitLab:
+
+   ```shell
+   sudo gitlab-ctl reconfigure
+   ```
+
+1. Run the Rake task to [migrate existing jobs](sidekiq_job_migration.md):
+
+   ```shell
+   sudo gitlab-rake gitlab:sidekiq:migrate_jobs:retry gitlab:sidekiq:migrate_jobs:schedule gitlab:sidekiq:migrate_jobs:queued
+   ```
+
+NOTE:
+It is important to run the Rake task immediately after reconfiguring GitLab.
+After reconfiguring GitLab, existing jobs are not processed until the Rake task starts to migrate the jobs.
+
+The following example better illustrates the migration process above:
+
+1. Check the following content of `/etc/gitlab/gitlab.rb`:
+
+   ```ruby
+   sidekiq['routing_rules'] = []
+   sidekiq['queue_selector'] = true
+   sidekiq['queue_groups'] = [
+     'urgency=high',
+     'urgency=low',
+     'urgency=throttled',
+     '*'
+   ]
+   ```
+
+1. Update `/etc/gitlab/gitlab.rb` to use routing rules:
+
+   ```ruby
+   sidekiq['min_concurrency'] = 20
+   sidekiq['max_concurrency'] = 20
+
+   sidekiq['routing_rules'] = [
+     ['urgency=high', 'high_urgency'],
+     ['urgency=low', 'low_urgency'],
+     ['urgency=throttled', 'throttled_urgency'],
+     # Wildcard matching, route the rest to `default` queue
+     ['*', 'default']
+   ]
+
+   sidekiq['queue_selector'] = false
+   sidekiq['queue_groups'] = [
+     'high_urgency',
+     'low_urgency',
+     'throttled_urgency',
+     'default'
+   ]
+   ```
+
+1. Save the file and reconfigure GitLab:
+
+   ```shell
+   sudo gitlab-ctl reconfigure
+   ```
+
+1. Run the Rake task to [migrate existing jobs](sidekiq_job_migration.md):
+
+   ```shell
+   sudo gitlab-rake gitlab:sidekiq:migrate_jobs:retry gitlab:sidekiq:migrate_jobs:schedule gitlab:sidekiq:migrate_jobs:queued
+   ```
+
+WARNING:
+As described in [the concurrency section](extra_sidekiq_processes.md#manage-thread-counts-explicitly), we
+recommend setting `min_concurrency` and `max_concurrency` to the same value. For example, if the number of queues
+in a queue group entry is 1, while `min_concurrency` is set to `0`, and `max_concurrency` is set to `20`, the resulting
+concurrency will be set to `2` instead. A concurrency of `2` might be too low in most cases, except for very highly-CPU
+bound tasks.
+
 ## Worker matching query
 
 GitLab provides a query syntax to match a worker based on its attributes. This
diff --git a/doc/administration/user_settings.md b/doc/administration/user_settings.md
index c96a6311208..b02e1c7244b 100644
--- a/doc/administration/user_settings.md
+++ b/doc/administration/user_settings.md
@@ -18,7 +18,7 @@ ability to create top-level groups (does not affect existing users' setting), Gi
   - The [application setting API](../api/settings.md#change-application-settings).
 - In GitLab 15.4 and earlier, in a configuration file by following the steps in this section.
 
-To disable new users' ability to create top-level groups using the configuation file:
+To disable new users' ability to create top-level groups using the configuration file:
 
 **Omnibus GitLab installations**
 
diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md
index adf558eb91d..79202e500b7 100644
--- a/doc/api/graphql/reference/index.md
+++ b/doc/api/graphql/reference/index.md
@@ -14675,6 +14675,20 @@ Represents the Geo replication and verification state of a job_artifact.
 | <a id="kasexternalurl"></a>`externalUrl` | [`String`](#string) | URL used by the Agents to communicate with KAS. |
 | <a id="kasversion"></a>`version` | [`String`](#string) | KAS version. |
 
+### `Key`
+
+Represents an SSH key.
+
+#### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="keycreatedat"></a>`createdAt` | [`Time!`](#time) | Timestamp of when the key was created. |
+| <a id="keyexpiresat"></a>`expiresAt` | [`Time!`](#time) | Timestamp of when the key expires. It's null if it never expires. |
+| <a id="keyid"></a>`id` | [`ID!`](#id) | ID of the key. |
+| <a id="keykey"></a>`key` | [`String!`](#string) | Public key of the key pair. |
+| <a id="keytitle"></a>`title` | [`String!`](#string) | Title of the key. |
+
 ### `Label`
 
 #### Fields
@@ -19202,6 +19216,20 @@ Represents the Geo sync and verification state of a snippet repository.
 | <a id="snippetrepositoryregistryverificationretryat"></a>`verificationRetryAt` | [`Time`](#time) | Timestamp after which the SnippetRepositoryRegistry is reverified. |
 | <a id="snippetrepositoryregistryverifiedat"></a>`verifiedAt` | [`Time`](#time) | Timestamp of the most recent successful verification of the SnippetRepositoryRegistry. |
 
+### `SshSignature`
+
+SSH signature for a signed commit.
+
+#### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="sshsignaturecommitsha"></a>`commitSha` | [`String`](#string) | SHA of the associated commit. |
+| <a id="sshsignaturekey"></a>`key` | [`Key`](#key) | SSH key used for the signature. |
+| <a id="sshsignatureproject"></a>`project` | [`Project`](#project) | Project of the associated commit. |
+| <a id="sshsignatureuser"></a>`user` | [`UserCore`](#usercore) | User associated with the key. |
+| <a id="sshsignatureverificationstatus"></a>`verificationStatus` | [`VerificationStatus`](#verificationstatus) | Indicates verification status of the associated key or certificate. |
+
 ### `StatusAction`
 
 #### Fields
@@ -23572,6 +23600,7 @@ Represents signing information for a commit.
 Implementations:
 
 - [`GpgSignature`](#gpgsignature)
+- [`SshSignature`](#sshsignature)
 - [`X509Signature`](#x509signature)
 
 ##### Fields
diff --git a/doc/api/packages/terraform-modules.md b/doc/api/packages/terraform-modules.md
index bb5b39b5161..6b3d6b477b2 100644
--- a/doc/api/packages/terraform-modules.md
+++ b/doc/api/packages/terraform-modules.md
@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 This is the API documentation for [Terraform Modules](../../user/packages/terraform_module_registry/index.md).
 
 WARNING:
-This API is used by the [terraform cli](https://www.terraform.io/)
+This API is used by the [Terraform CLI](https://www.terraform.io/)
 and is generally not meant for manual consumption.
 
 For instructions on how to upload and install Terraform modules from the GitLab
diff --git a/doc/api/pipelines.md b/doc/api/pipelines.md
index 8242f8cff00..669161049d5 100644
--- a/doc/api/pipelines.md
+++ b/doc/api/pipelines.md
@@ -274,7 +274,7 @@ Sample response:
 Get the latest pipeline for a specific ref in a project.
 
 ```plaintext
-POST /projects/:id/pipeline/latest
+GET /projects/:id/pipelines/latest
 ```
 
 | Attribute   | Type    | Required | Description         |
diff --git a/doc/architecture/blueprints/ci_data_decay/pipeline_partitioning.md b/doc/architecture/blueprints/ci_data_decay/pipeline_partitioning.md
index 6f58b7852a6..71f7af62785 100644
--- a/doc/architecture/blueprints/ci_data_decay/pipeline_partitioning.md
+++ b/doc/architecture/blueprints/ci_data_decay/pipeline_partitioning.md
@@ -370,7 +370,7 @@ system - any letter from `g` to `z` in Latin alphabet, for example `x`. In that
 case an example of an URI would look like `1e240x5ba0`. If we decide to update
 the primary identifier of a partitioned resource (today it is just a big
 integer) it is important to design a system that is resilient to migrating data
-between partitions, to avoid changing idenfiers when rebalancing happens.
+between partitions, to avoid changing identifiers when rebalancing happens.
 
 `ci_partitions` table will store information about a partition identifier,
 pipeline ids range it is valid for and whether the partitions have been
diff --git a/doc/architecture/blueprints/pods/index.md b/doc/architecture/blueprints/pods/index.md
index 0003fb3ea2c..0a36de5790f 100644
--- a/doc/architecture/blueprints/pods/index.md
+++ b/doc/architecture/blueprints/pods/index.md
@@ -335,6 +335,7 @@ This is the list of known affected features with the proposed solutions.
 - [Pods: Snippets](pods-feature-snippets.md)
 - [Pods: Uploads](pods-feature-uploads.md)
 - [Pods: GitLab Pages](pods-feature-gitlab-pages.md)
+- [Pods: Agent for Kubernetes](pods-feature-agent-for-kubernetes.md)
 
 ## Links
 
diff --git a/doc/architecture/blueprints/pods/pods-feature-agent-for-kubernetes.md b/doc/architecture/blueprints/pods/pods-feature-agent-for-kubernetes.md
new file mode 100644
index 00000000000..f390c751b8b
--- /dev/null
+++ b/doc/architecture/blueprints/pods/pods-feature-agent-for-kubernetes.md
@@ -0,0 +1,29 @@
+---
+stage: enablement
+group: pods
+comments: false
+description: 'Pods: Agent for Kubernetes'
+---
+
+This document is a work-in-progress and represents a very early state of the
+Pods design. Significant aspects are not documented, though we expect to add
+them in the future. This is one possible architecture for Pods, and we intend to
+contrast this with alternatives before deciding which approach to implement.
+This documentation will be kept even if we decide not to implement this so that
+we can document the reasons for not choosing this approach.
+
+# Pods: Agent for Kubernetes
+
+> TL;DR
+
+## 1. Definition
+
+## 2. Data flow
+
+## 3. Proposal
+
+## 4. Evaluation
+
+## 4.1. Pros
+
+## 4.2. Cons
diff --git a/doc/architecture/blueprints/work_items/index.md b/doc/architecture/blueprints/work_items/index.md
index 75a9d8d76ad..7f980c2a017 100644
--- a/doc/architecture/blueprints/work_items/index.md
+++ b/doc/architecture/blueprints/work_items/index.md
@@ -60,7 +60,7 @@ All Work Item types share the same pool of predefined widgets and are customized
 | assignees  | |
 | description | |
 | hierarchy | |
-| [iteration](https://gitlab.com/gitlab-org/gitlab/-/issues/367456) | work_items_mvc_2 |
+| [iteration](https://gitlab.com/gitlab-org/gitlab/-/issues/367456) | |
 | [milestone](https://gitlab.com/gitlab-org/gitlab/-/issues/367463) | work_items_mvc_2 |
 | labels | |
 | start and due date | |
diff --git a/doc/gitlab-basics/start-using-git.md b/doc/gitlab-basics/start-using-git.md
index 25ef094b2a7..61b06fb106a 100644
--- a/doc/gitlab-basics/start-using-git.md
+++ b/doc/gitlab-basics/start-using-git.md
@@ -172,7 +172,7 @@ add your namespace (username or group) to the path:
 Clone with HTTPS using a token if:
 
 - You want to use 2FA.
-- You want to have a revokable set of credentials scoped to one or more repositories.
+- You want to have a revocable set of credentials scoped to one or more repositories.
 
 You can use any of these tokens to authenticate when cloning over HTTPS:
 
diff --git a/doc/user/admin_area/index.md b/doc/user/admin_area/index.md
index 4c34d82dc02..c9b6a077c73 100644
--- a/doc/user/admin_area/index.md
+++ b/doc/user/admin_area/index.md
@@ -163,7 +163,7 @@ You can impersonate a user in the following ways:
   1. Select **Impersonate**.
 - With the API, using [impersonation tokens](../../api/index.md#impersonation-tokens).
 
-All impersonation activities are [captured with audit events](../../administration/audit_events.md#impersonation-data).
+All impersonation activities are [captured with audit events](../../administration/audit_events.md#user-impersonation).
 
 By default, impersonation is enabled. GitLab can be configured to [disable impersonation](../../api/index.md#disable-impersonation).
 
diff --git a/doc/user/group/saml_sso/group_sync.md b/doc/user/group/saml_sso/group_sync.md
index 001c73b6979..6447d8ab750 100644
--- a/doc/user/group/saml_sso/group_sync.md
+++ b/doc/user/group/saml_sso/group_sync.md
@@ -10,9 +10,9 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/363084) for self-managed instances in GitLab 15.1.
 
 WARNING:
-Changing Group Sync configuration can remove users from the mapped GitLab group.
+Adding or changing Group Sync configuration can remove users from the mapped GitLab group.
 Removal happens if there is any mismatch between the group names and the list of `groups` in the SAML response.
-If changes must be made, ensure either the SAML response includes the `groups` attribute
+Before making changes, ensure either the SAML response includes the `groups` attribute
 and the `AttributeValue` value matches the **SAML Group Name** in GitLab,
 or that all groups are removed from GitLab to disable Group Sync.
 
@@ -21,14 +21,18 @@ For a demo of Group Sync using Azure, see [Demo: SAML Group Sync](https://youtu.
 
 ## Configure SAML Group Sync
 
+To prevent users being accidentally removed from the GitLab group, follow these instructions closely before
+enabling Group Sync in GitLab.
+
 To configure SAML Group Sync:
 
-- For GitLab self-managed:
-  1. Configure the [SAML OmniAuth Provider](../../../integration/saml.md).
-  1. Ensure your SAML identity provider sends an attribute statement with the same name as the value of the `groups_attribute` setting.
-- For GitLab.com:
-  1. See [SAML SSO for GitLab.com groups](index.md).
-  1. Ensure your SAML identity provider sends an attribute statement named `Groups` or `groups`.
+1. Configure the identity Provider:
+   - For self-managed GitLab, see the [SAML OmniAuth Provider documentation](../../../integration/saml.md).
+   - For GitLab.com, see the [SAML SSO for GitLab.com groups documentation](index.md).
+
+1. Capture [a SAML response](troubleshooting.md#saml-debugging-tools) during the sign-in process to confirm your SAML identity provider sends an attribute statement:
+   - For self-managed GitLab, with the same name as the value of the `groups_attribute` setting.
+   - For GitLab.com, named `Groups` or `groups`.
 
 NOTE:
 The value for `Groups` or `groups` in the SAML response can be either the group name or the group ID.
diff --git a/doc/user/tasks.md b/doc/user/tasks.md
index 5fed887ca74..71f427f11c1 100644
--- a/doc/user/tasks.md
+++ b/doc/user/tasks.md
@@ -249,10 +249,13 @@ To set issue weight of a task:
 
 ## Add a task to an iteration **(PREMIUM)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/367456) in GitLab 15.5 [with a flag](../administration/feature_flags.md) named `work_items_mvc_2`. Disabled by default.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/367456) in GitLab 15.5 [with a flag](../administration/feature_flags.md) named `work_items_mvc_2`. Disabled by default.
+> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/367456) to feature flag named `work_items_mvc` in GitLab 15.7. Disabled by default.
+> - [Enabled on GitLab.com and self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/367456) in GitLab 15.7.
 
 FLAG:
-On self-managed GitLab, by default this feature is not available. To make it available per group, ask an administrator to [enable the feature flag](../administration/feature_flags.md) named `work_items_mvc_2`. On GitLab.com, this feature is not available. The feature is not ready for production use.
+On self-managed GitLab, by default this feature is available. To hide the feature, ask an administrator to [disable the feature flag](../administration/feature_flags.md) named `work_items_mvc`.
+On GitLab.com, this feature is available.
 
 You can add a task to an [iteration](group/iterations/index.md).
 You can see the iteration title and period only when you view a task.