Add latest changes from gitlab-org/gitlab@master

10 files changed, 130 insertions, 72 deletions

diff --git a/doc/administration/pages/index.md b/doc/administration/pages/index.md
index ed08b10fe97..efd2f2039d1 100644
--- a/doc/administration/pages/index.md
+++ b/doc/administration/pages/index.md
@@ -631,34 +631,6 @@ are stored.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
 
-Alternatively, if you have existing Pages deployed you can follow
-the below steps to do a no downtime transfer to a new storage location.
-
-1. Pause Pages deployments by setting the following in `/etc/gitlab/gitlab.rb`:
-
-   ```ruby
-   sidekiq['queue_selector'] = true
-   sidekiq['queue_groups'] = [
-     "feature_category!=pages"
-   ]
-   ```
-
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
-1. `rsync` contents from the current storage location to the new storage location: `sudo rsync -avzh --progress /var/opt/gitlab/gitlab-rails/shared/pages/ /mnt/storage/pages`
-1. Set the new storage location in `/etc/gitlab/gitlab.rb`:
-
-   ```ruby
-   gitlab_rails['pages_path'] = "/mnt/storage/pages"
-   ```
-
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
-1. Verify Pages are still being served up as expected.
-1. Resume Pages deployments by removing from `/etc/gitlab/gitlab.rb` the `sidekiq` setting set above.
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
-1. Trigger a new Pages deployment and verify it's working as expected.
-1. Remove the old Pages storage location: `sudo rm -rf /var/opt/gitlab/gitlab-rails/shared/pages`
-1. Verify Pages are still being served up as expected.
-
 ## Configure listener for reverse proxy requests
 
 Follow the steps below to configure the proxy listener of GitLab Pages.
diff --git a/doc/administration/sidekiq/processing_specific_job_classes.md b/doc/administration/sidekiq/processing_specific_job_classes.md
index 61a154c8db2..0e4a0662277 100644
--- a/doc/administration/sidekiq/processing_specific_job_classes.md
+++ b/doc/administration/sidekiq/processing_specific_job_classes.md
@@ -17,7 +17,7 @@ job classes:
 1. [Routing rules](#routing-rules) are used on GitLab.com. They direct jobs
    inside the application to queue names configured by administrators. This
    lowers the load on Redis, which is important on very large-scale deployments.
-1. [Queue selectors](#queue-selectors) perform the job selection outside the
+1. [Queue selectors](#queue-selectors-deprecated) perform the job selection outside the
    application, when starting the Sidekiq process. This was used on GitLab.com
    until September 2021, and is retained for compatibility reasons.
 
@@ -106,11 +106,19 @@ not a recommendation.
    sudo gitlab-ctl reconfigure
    ```
 
-## Queue selectors
+<!--- start_remove The following content will be removed on remove_date: '2024-08-22' -->
+
+## Queue selectors (deprecated)
 
 > - [Introduced](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/45) in GitLab 12.8.
 > - [Sidekiq cluster, including queue selector, moved](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/181) to GitLab Free in 12.10.
 > - [Renamed from `experimental_queue_selector` to `queue_selector`](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/147) in GitLab 13.6.
+> - [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/390787) in GitLab 15.9.
+
+WARNING:
+This feature was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/390787) in GitLab 15.9
+and is planned for removal in 17.0. Most instances should have [all processes to listen to all queues](extra_sidekiq_processes.md#start-multiple-processes).
+Another alternative is to use [routing rules](#routing-rules) (be warned this is an advanced setting). This change is a breaking change.
 
 The `queue_selector` option allows queue groups to be selected in a more general
 way using a [worker matching query](#worker-matching-query). After
@@ -141,7 +149,12 @@ syntax.
    sudo gitlab-ctl reconfigure
    ```
 
-### Negate settings
+### Negate settings (deprecated)
+
+WARNING:
+This feature was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/390787) in GitLab 15.9
+and is planned for removal in 17.0. Most instances should have [all processes to listen to all queues](extra_sidekiq_processes.md#start-multiple-processes).
+Another alternative is to use [routing rules](#routing-rules) (be warned this is an advanced setting). This change is a breaking change.
 
 This allows you to have the Sidekiq process work on every queue **except** the
 ones you list. This is generally only used when there are multiple Sidekiq
@@ -168,7 +181,7 @@ nodes. In this example, we exclude all import-related jobs from a Sidekiq node.
 
 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
+[routing rules](#routing-rules) instead of [queue selectors](#queue-selectors-deprecated). We use routing rules on GitLab.com as
 it helps to lower the load on Redis.
 
 To migrate from queue selectors to routing rules:
@@ -255,11 +268,13 @@ in a queue group entry is 1, while `min_concurrency` is set to `0`, and `max_con
 concurrency is set to `2` instead. A concurrency of `2` might be too low in most cases, except for very highly-CPU
 bound tasks.
 
+<!--- end_remove -->
+
 ## Worker matching query
 
 GitLab provides a query syntax to match a worker based on its attributes. This
 query syntax is employed by both [routing rules](#routing-rules) and
-[queue selectors](#queue-selectors). A query includes two components:
+[queue selectors](#queue-selectors-deprecated). A query includes two components:
 
 - Attributes that can be selected.
 - Operators used to construct a query.
diff --git a/doc/development/service_ping/implement.md b/doc/development/service_ping/implement.md
index af3a73144b2..d8bb00dc43a 100644
--- a/doc/development/service_ping/implement.md
+++ b/doc/development/service_ping/implement.md
@@ -754,7 +754,7 @@ To set up Service Ping locally, you must:
    Make sure you run `docker-compose up` to start a PostgreSQL and Redis instance.
 1. Point GitLab to the Versions Application endpoint instead of the default endpoint:
    1. Open [service_ping/submit_service.rb](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/services/service_ping/submit_service.rb#L5) locally and modify `STAGING_BASE_URL`.
-   1. Set it to the local Versions Application URL: `http://localhost:3000/usage_data`.
+   1. Set it to the local Versions Application URL: `http://localhost:3000`.
 
 ### Test local setup
 
diff --git a/doc/integration/advanced_search/elasticsearch.md b/doc/integration/advanced_search/elasticsearch.md
index 6a2c562377f..b2ca9346982 100644
--- a/doc/integration/advanced_search/elasticsearch.md
+++ b/doc/integration/advanced_search/elasticsearch.md
@@ -862,6 +862,10 @@ However, some larger installations may wish to tune the merge policy settings:
 
 ## Index large instances with dedicated Sidekiq nodes or processes
 
+WARNING:
+Most instances should not need to configure this. The steps below use an advanced setting of Sidekiq called [routing rules](../../administration/sidekiq/processing_specific_job_classes.md#routing-rules).
+Be sure to fully understand about the implication of using routing rules to avoid losing jobs entirely.
+
 Indexing a large instance can be a lengthy and resource-intensive process that has the potential
 of overwhelming Sidekiq nodes and processes. This negatively affects the GitLab performance and
 availability.
@@ -871,18 +875,20 @@ additional process dedicated to indexing a set of queues (or queue group). This
 ensure that indexing queues always have a dedicated worker, while the rest of the queues have
 another dedicated worker to avoid contention.
 
-For this purpose, use the [queue selectors](../../administration/sidekiq/processing_specific_job_classes.md#queue-selectors)
-option that allows a more general selection of queue groups using a [worker matching query](../../administration/sidekiq/processing_specific_job_classes.md#worker-matching-query).
+For this purpose, use the [routing rules](../../administration/sidekiq/processing_specific_job_classes.md#routing-rules)
+option that allows Sidekiq to route jobs to a specific queue based on [worker matching query](../../administration/sidekiq/processing_specific_job_classes.md#worker-matching-query).
 
-To handle these two queue groups, we generally recommend one of the following two options. You can either:
+To handle this, we generally recommend one of the following two options. You can either:
 
 - [Use two queue groups on one single node](#single-node-two-processes).
 - [Use two queue groups, one on each node](#two-nodes-one-process-for-each).
 
-For the steps below, consider:
+For the steps below, consider the entry of `sidekiq['routing_rules']`:
+
+- `["feature_category=global_search", "global_search"]` as all indexing jobs are routed to the `global_search` queue.
+- `["*", "default"]` as all other non-indexing jobs are routed to the `default` queue.
 
-- `feature_category=global_search` as an indexing queue group with its own Sidekiq process.
-- `feature_category!=global_search` as a non-indexing queue group that has its own Sidekiq process.
+Note that at least one process in `sidekiq['queue_groups']` has to include the `mailers` queue, otherwise mailers jobs are not processed at all.
 
 ### Single node, two processes
 
@@ -892,11 +898,20 @@ To create both an indexing and a non-indexing Sidekiq process in one node:
 
    ```ruby
    sidekiq['enable'] = true
-   sidekiq['queue_selector'] = true
+   sidekiq['queue_selector'] = false
+
+   sidekiq['routing_rules'] = [
+      ["feature_category=global_search", "global_search"],
+      ["*", "default"],
+   ]
+
    sidekiq['queue_groups'] = [
-      "feature_category=global_search",
-      "feature_category!=global_search"
-    ]
+      "global_search", # process that listens to global_search queue
+      "default,mailers" # process that listens to default and mailers queue
+   ]
+
+   sidekiq['min_concurrency'] = 20
+   sidekiq['max_concurrency'] = 20
    ```
 
 1. Save the file and [reconfigure GitLab](../../administration/restart_gitlab.md)
@@ -914,26 +929,42 @@ To handle these queue groups on two nodes:
 
 1. To set up the indexing Sidekiq process, on your indexing Sidekiq node, change the `/etc/gitlab/gitlab.rb` file to:
 
-    ```ruby
-    sidekiq['enable'] = true
-     sidekiq['queue_selector'] = true
-     sidekiq['queue_groups'] = [
-       "feature_category=global_search"
-     ]
-    ```
+   ```ruby
+   sidekiq['enable'] = true
+   sidekiq['queue_selector'] = false
+
+   sidekiq['routing_rules'] = [
+      ["feature_category=global_search", "global_search"],
+      ["*", "default"],
+   ]
+
+   sidekiq['queue_groups'] = [
+     "global_search", # process that listens to global_search queue
+   ]
+
+   sidekiq['min_concurrency'] = 20
+   sidekiq['max_concurrency'] = 20
+   ```
 
 1. Save the file and [reconfigure GitLab](../../administration/restart_gitlab.md)
 for the changes to take effect.
 
 1. To set up the non-indexing Sidekiq process, on your non-indexing Sidekiq node, change the `/etc/gitlab/gitlab.rb` file to:
 
-    ```ruby
-    sidekiq['enable'] = true
-     sidekiq['queue_selector'] = true
-     sidekiq['queue_groups'] = [
-       "feature_category!=global_search"
-     ]
-    ```
+   ```ruby
+   sidekiq['enable'] = true
+   sidekiq['routing_rules'] = [
+      ["feature_category=global_search", "global_search"],
+      ["*", "default"],
+   ]
+
+   sidekiq['queue_groups'] = [
+      "default,mailers" # process that listens to default and mailers queue
+   ]
+
+   sidekiq['min_concurrency'] = 20
+   sidekiq['max_concurrency'] = 20
+   ```
 
     to set up a non-indexing Sidekiq process.
 
diff --git a/doc/integration/advanced_search/elasticsearch_troubleshooting.md b/doc/integration/advanced_search/elasticsearch_troubleshooting.md
index c8d11286a3c..f2f732386a7 100644
--- a/doc/integration/advanced_search/elasticsearch_troubleshooting.md
+++ b/doc/integration/advanced_search/elasticsearch_troubleshooting.md
@@ -248,7 +248,7 @@ sudo gitlab-rake gitlab:elastic:clear_locked_projects
 If `ElasticCommitIndexerWorker` Sidekiq workers are failing with this error during indexing, it usually means that Elasticsearch is unable to keep up with the concurrency of indexing request. To address change the following settings:
 
 - To decrease the indexing throughput you can decrease `Bulk request concurrency` (see [Advanced Search settings](elasticsearch.md#advanced-search-configuration)). This is set to `10` by default, but you change it to as low as 1 to reduce the number of concurrent indexing operations.
-- If changing `Bulk request concurrency` didn't help, you can use the [queue selector](../../administration/sidekiq/processing_specific_job_classes.md#queue-selectors) option to [limit indexing jobs only to specific Sidekiq nodes](elasticsearch.md#index-large-instances-with-dedicated-sidekiq-nodes-or-processes), which should reduce the number of indexing requests.
+- If changing `Bulk request concurrency` didn't help, you can use the [routing rules](../../administration/sidekiq/processing_specific_job_classes.md#routing-rules) option to [limit indexing jobs only to specific Sidekiq nodes](elasticsearch.md#index-large-instances-with-dedicated-sidekiq-nodes-or-processes), which should reduce the number of indexing requests.
 
 ### Indexing is very slow or fails with `rejected execution of coordinating operation` messages
 
diff --git a/doc/integration/ding_talk.md b/doc/integration/ding_talk.md
index ca939dc9f9a..cb7ba6849b9 100644
--- a/doc/integration/ding_talk.md
+++ b/doc/integration/ding_talk.md
@@ -6,7 +6,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # DingTalk OAuth 2.0 OmniAuth provider **(FREE SELF)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/341898) in GitLab 14.5.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/341898) in GitLab 14.5.
+> - [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/390855) in GitLab 15.10.
 
 You can sign in to GitLab using your DingTalk account.
 Sign in to DingTalk Open Platform and create an application on it. DingTalk generates a client ID and secret key for you to use.
diff --git a/doc/update/deprecations.md b/doc/update/deprecations.md
index 188e0f7fe83..1aff4d3c4a1 100644
--- a/doc/update/deprecations.md
+++ b/doc/update/deprecations.md
@@ -48,6 +48,26 @@ sole discretion of GitLab Inc.
 
 <div class="announcement-milestone">
 
+## Announced in 15.10
+
+<div class="deprecation removal-1700 breaking-change">
+
+### DingTalk OmniAuth provider
+
+Planned removal: GitLab <span class="removal-milestone">17.00</span> <span class="removal-date"></span>
+
+WARNING:
+This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
+Review the details carefully before upgrading.
+
+The `omniauth-dingtalk` gem that provides GitLab with the DingTalk OmniAuth provider will be removed in our next
+major release, GitLab 17.0. This gem sees very little use and is better suited for JiHu edition.
+
+</div>
+</div>
+
+<div class="announcement-milestone">
+
 ## Announced in 15.9
 
 <div class="deprecation removal-170 breaking-change">
diff --git a/doc/update/index.md b/doc/update/index.md
index 18f409dc922..e4f116d420a 100644
--- a/doc/update/index.md
+++ b/doc/update/index.md
@@ -620,9 +620,7 @@ and [Helm Chart deployments](https://docs.gitlab.com/charts/). They come with ap
 
 ### 15.5.3
 
-- GitLab 15.4.0 introduced a default [Sidekiq routing rule](../administration/sidekiq/processing_specific_job_classes.md#routing-rules) that routes all jobs
-  to the `default` queue. For instances using [queue selectors](../administration/sidekiq/processing_specific_job_classes.md#queue-selectors), this causes
-  [performance problems](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/1991) as some Sidekiq processes are idle.
+- GitLab 15.4.0 introduced a default [Sidekiq routing rule](../administration/sidekiq/processing_specific_job_classes.md#routing-rules) that routes all jobs to the `default` queue. For instances using [queue selectors](../administration/sidekiq/processing_specific_job_classes.md#queue-selectors-deprecated), this causes [performance problems](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/1991) as some Sidekiq processes will be idle.
   - The default routing rule has been reverted in 15.5.4, so upgrading to that version or later will return to the previous behavior.
   - If a GitLab instance now listens only to the `default` queue (which is not currently recommended), it will be required to add this routing rule back in `/etc/gitlab/gitlab.rb`:
 
@@ -634,7 +632,7 @@ and [Helm Chart deployments](https://docs.gitlab.com/charts/). They come with ap
 
 ### 15.5.2
 
-- GitLab 15.4.0 introduced a default Sidekiq routing rule that routes all jobs to the `default` queue. For instances using [queue selectors](../administration/sidekiq/processing_specific_job_classes.md#queue-selectors), this will cause [performance problems](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/1991) as some Sidekiq processes will be idle.
+- GitLab 15.4.0 introduced a default [Sidekiq routing rule](../administration/sidekiq/processing_specific_job_classes.md#routing-rules) that routes all jobs to the `default` queue. For instances using [queue selectors](../administration/sidekiq/processing_specific_job_classes.md#queue-selectors-deprecated), this causes [performance problems](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/1991) as some Sidekiq processes will be idle.
   - The default routing rule has been reverted in 15.5.4, so upgrading to that version or later will return to the previous behavior.
   - If a GitLab instance now listens only to the `default` queue (which is not currently recommended), it will be required to add this routing rule back in `/etc/gitlab/gitlab.rb`:
 
@@ -646,7 +644,7 @@ and [Helm Chart deployments](https://docs.gitlab.com/charts/). They come with ap
 
 ### 15.5.1
 
-- GitLab 15.4.0 introduced a default Sidekiq routing rule that routes all jobs to the `default` queue. For instances using [queue selectors](../administration/sidekiq/processing_specific_job_classes.md#queue-selectors), this will cause [performance problems](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/1991) as some Sidekiq processes will be idle.
+- GitLab 15.4.0 introduced a default [Sidekiq routing rule](../administration/sidekiq/processing_specific_job_classes.md#routing-rules) that routes all jobs to the `default` queue. For instances using [queue selectors](../administration/sidekiq/processing_specific_job_classes.md#queue-selectors-deprecated), this causes [performance problems](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/1991) as some Sidekiq processes will be idle.
   - The default routing rule has been reverted in 15.5.4, so upgrading to that version or later will return to the previous behavior.
   - If a GitLab instance now listens only to the `default` queue (which is not currently recommended), it will be required to add this routing rule back in `/etc/gitlab/gitlab.rb`:
 
@@ -658,7 +656,7 @@ and [Helm Chart deployments](https://docs.gitlab.com/charts/). They come with ap
 
 ### 15.5.0
 
-- GitLab 15.4.0 introduced a default Sidekiq routing rule that routes all jobs to the `default` queue. For instances using [queue selectors](../administration/sidekiq/processing_specific_job_classes.md#queue-selectors), this will cause [performance problems](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/1991) as some Sidekiq processes will be idle.
+- GitLab 15.4.0 introduced a default [Sidekiq routing rule](../administration/sidekiq/processing_specific_job_classes.md#routing-rules) that routes all jobs to the `default` queue. For instances using [queue selectors](../administration/sidekiq/processing_specific_job_classes.md#queue-selectors-deprecated), this causes [performance problems](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/1991) as some Sidekiq processes will be idle.
   - The default routing rule has been reverted in 15.5.4, so upgrading to that version or later will return to the previous behavior.
   - If a GitLab instance now listens only to the `default` queue (which is not currently recommended), it will be required to add this routing rule back in `/etc/gitlab/gitlab.rb`:
 
@@ -709,7 +707,7 @@ and [Helm Chart deployments](https://docs.gitlab.com/charts/). They come with ap
 - GitLab 15.4.0 includes a [batched background migration](background_migrations.md#batched-background-migrations) to [remove incorrect values from `expire_at` in `ci_job_artifacts` table](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/89318).
   This migration might take hours or days to complete on larger GitLab instances.
 - By default, Gitaly and Praefect nodes use the time server at `pool.ntp.org`. If your instance can not connect to `pool.ntp.org`, [configure the `NTP_HOST` variable](../administration/gitaly/praefect.md#customize-time-server-setting).
-- GitLab 15.4.0 introduced a default Sidekiq routing rule that routes all jobs to the `default` queue. For instances using [queue selectors](../administration/sidekiq/processing_specific_job_classes.md#queue-selectors), this will cause [performance problems](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/1991) as some Sidekiq processes will be idle.
+- GitLab 15.4.0 introduced a default [Sidekiq routing rule](../administration/sidekiq/processing_specific_job_classes.md#routing-rules) that routes all jobs to the `default` queue. For instances using [queue selectors](../administration/sidekiq/processing_specific_job_classes.md#queue-selectors-deprecated), this causes [performance problems](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/1991) as some Sidekiq processes will be idle.
   - The default routing rule has been reverted in 15.4.5, so upgrading to that version or later will return to the previous behavior.
   - If a GitLab instance now listens only to the `default` queue (which is not currently recommended), it will be required to add this routing rule back in `/etc/gitlab/gitlab.rb`:
 
diff --git a/doc/user/group/access_and_permissions.md b/doc/user/group/access_and_permissions.md
index a04178acfbb..e061d0070e1 100644
--- a/doc/user/group/access_and_permissions.md
+++ b/doc/user/group/access_and_permissions.md
@@ -286,7 +286,15 @@ To create group links via filter:
 LDAP user permissions can be manually overridden by an administrator. To override a user's permissions:
 
 1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Group information > Members**.
+1. On the left sidebar, select **Group information > Members**. If LDAP synchronization
+   has granted a user a role with:
+   - More permissions than the parent group membership, that user is displayed as having
+     [direct membership](../project/members/index.md#display-direct-members) of the group.
+   - The same or fewer permissions than the parent group membership, that user is displayed as having
+     [inherited membership](../project/members/index.md#display-inherited-members) of the group.
+1. Optional. If the user you want to edit is displayed as having inherited membership,
+   [filter the subgroup to show direct members](manage.md#filter-a-group) before
+   overriding LDAP user permissions.
 1. In the row for the user you are editing, select the pencil (**{pencil}**) icon.
 1. Select **Edit permissions** in the modal.
 
@@ -302,3 +310,17 @@ If a user sees a 404 when they would usually expect access, and the problem is l
 - `json.allowed`: `false`
 
 In viewing the log entries, compare `remote.ip` with the list of [allowed IP addresses](#restrict-group-access-by-ip-address) for the group.
+
+### Cannot update permissions for a group member
+
+If a group Owner cannot update permissions for a group member, check which memberships
+are listed. Group Owners can only update direct memberships.
+
+If a parent group membership has the same or higher role than a subgroup, the
+[inherited membership](../project/members/index.md#inherited-membership) is
+listed on the subgroup members page, even if a [direct membership](../project/members/index.md#membership-types)
+on the group exists.
+
+To view and update direct memberships, [filter the group to show direct members](manage.md#filter-a-group).
+
+The need to filter members by type through a redesigned members page that lists both direct and inherited memberships is proposed in [issue 337539](https://gitlab.com/gitlab-org/gitlab/-/issues/337539#note_1277786161).
diff --git a/doc/user/group/saml_sso/index.md b/doc/user/group/saml_sso/index.md
index e650b2dd130..cd2859abcfe 100644
--- a/doc/user/group/saml_sso/index.md
+++ b/doc/user/group/saml_sso/index.md
@@ -181,9 +181,6 @@ SSO enforcement for web activity has the following effects when enabled:
 
 - For groups, users cannot share a project in the group outside the top-level
   group, even if the project is forked.
-- For Git activity over SSH and HTTPS, users must have at least one active
-  session signed-in through SSO before they can push to or
-  pull from a GitLab repository.
 - Git activity originating from CI/CD jobs do not have the SSO check enforced.
 - Credentials that are not tied to regular users (for example, project and group
   access tokens, and deploy keys) do not have the SSO check enforced.
@@ -192,7 +189,9 @@ SSO enforcement for web activity has the following effects when enabled:
 - When the **Enforce SSO-only authentication for Git and Dependency Proxy
   activity for this group** option is enabled, any API endpoint that involves
   Git activity is under SSO enforcement. For example, creating or deleting a
-  branch, commit, or tag.
+  branch, commit, or tag. For Git activity over SSH and HTTPS, users must
+  have at least one active session signed-in through SSO before they can push to or
+  pull from a GitLab repository.
 
 When SSO for web activity is enforced, non-SSO group members do not lose access
 immediately. If the user: