Add latest changes from gitlab-org/gitlab@master

7 files changed, 95 insertions, 24 deletions

diff --git a/doc/api/oauth2.md b/doc/api/oauth2.md
index 528f012c7a8..02904f2be5b 100644
--- a/doc/api/oauth2.md
+++ b/doc/api/oauth2.md
@@ -82,7 +82,11 @@ Before starting the flow, generate the `STATE`, the `CODE_VERIFIER` and the `COD
   which use the characters `A-Z`, `a-z`, `0-9`, `-`, `.`, `_`, and `~`.
 - The `CODE_CHALLENGE` is an URL-safe base64-encoded string of the SHA256 hash of the
   `CODE_VERIFIER`
+  - The SHA256 hash must be in binary format before encoding.
   - In Ruby, you can set that up with `Base64.urlsafe_encode64(Digest::SHA256.digest(CODE_VERIFIER), padding: false)`.
+  - For reference, a `CODE_VERIFIER` string of `ks02i3jdikdo2k0dkfodf3m39rjfjsdk0wk349rj3jrhf` when hashed 
+    and encoded using the Ruby snippet above produces a `CODE_CHALLENGE` string 
+    of `2i0WFA-0AerkjQm4X4oDEhqA17QIAKNjXpagHBXmO_U`.
 
 1. Request authorization code. To do that, you should redirect the user to the
    `/oauth/authorize` page with the following query parameters:
diff --git a/doc/api/settings.md b/doc/api/settings.md
index e640500c4ad..4388e9bd646 100644
--- a/doc/api/settings.md
+++ b/doc/api/settings.md
@@ -421,6 +421,7 @@ listed in the descriptions of the relevant settings.
 | `unique_ips_limit_per_user`              | integer          | required by: `unique_ips_limit_enabled` | Maximum number of IPs per user. |
 | `unique_ips_limit_time_window`           | integer          | required by: `unique_ips_limit_enabled` | How many seconds an IP is counted towards the limit. |
 | `usage_ping_enabled`                     | boolean          | no                                   | Every week GitLab reports license usage back to GitLab, Inc. |
+| `user_deactivation_emails_enabled`       | boolean          | no                                   | Send an email to users upon account deactivation. |
 | `user_default_external`                  | boolean          | no                                   | Newly registered users are external by default. |
 | `user_default_internal_regex`            | string           | no                                   | Specify an email address regex pattern to identify default internal users. |
 | `user_oauth_applications`                | boolean          | no                                   | Allow users to register any application to use GitLab as an OAuth provider. |
diff --git a/doc/development/database/multiple_databases.md b/doc/development/database/multiple_databases.md
index aaad4fa22e6..c8f4ab01d16 100644
--- a/doc/development/database/multiple_databases.md
+++ b/doc/development/database/multiple_databases.md
@@ -98,22 +98,45 @@ and their tables must be placed in two directories for now:
 
 We aim to keep the schema for both tables the same across both databases.
 
+<!--
+NOTE: The `validate_cross_joins!` method in `spec/support/database/prevent_cross_joins.rb` references
+      the following heading in the code, so if you make a change to this heading, make sure to update
+      the corresponding documentation URL used in `spec/support/database/prevent_cross_joins.rb`.
+-->
+
 ### Removing joins between `ci_*` and non `ci_*` tables
 
-We are planning on moving all the `ci_*` tables to a separate database so
+Queries that join across databases raise an error. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/68620)
+in GitLab 14.3, for new queries only. Pre-existing queries do not raise an error.
+
+We are planning on moving all the `ci_*` tables to a separate database, so
 referencing `ci_*` tables with other tables will not be possible. This means,
 that using any kind of `JOIN` in SQL queries will not work. We have identified
 already many such examples that need to be fixed in
 <https://gitlab.com/groups/gitlab-org/-/epics/6289> .
 
-The following are some real examples that have resulted from this and these
-patterns may apply to future cases.
+#### Path to removing cross-database joins
+
+The following steps are the process to remove cross-database joins between
+`ci_*` and non `ci_*` tables:
+
+1. **{check-circle}** Add all failing specs to the [`cross-join-allowlist.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/f5de89daeb468fc45e1e95a76d1b5297aa53da11/spec/support/database/cross-join-allowlist.yml)
+   file.
+1. **{dotted-circle}** Find the code that caused the spec failure and wrap the isolated code
+   in [`allow_cross_joins_across_databases`](#allowlist-for-existing-cross-joins).
+   Link to a new issue assigned to the correct team to remove the specs from the
+   `cross-join-allowlist.yml` file.
+1. **{dotted-circle}** Remove the `cross-join-allowlist.yml` file and stop allowing
+   whole test files.
+1. **{dotted-circle}** Fix the problem and remove the `allow_cross_joins_across_databases` call.
+1. **{dotted-circle}** Fix all the cross-joins and remove the `allow_cross_joins_across_databases` method.
 
-[Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/68620) in GitLab 14.3, any
-queries detected that join across databases raises an error (except
-for pre-existing queries).
+#### Suggestions for removing cross-database joins
 
-#### Remove the code
+The following sections are some real examples that were identified as joining across databases,
+along with possible suggestions on how to fix them.
+
+##### Remove the code
 
 The simplest solution we've seen several times now has been an existing scope
 that is unused. This is the easiest example to fix. So the first step is to
@@ -135,7 +158,7 @@ to evaluate, because `UsageData` is not critical to users and it may be possible
 to get a similarly useful metric with a simpler approach. Alternatively we may
 find that nobody is using these metrics, so we can remove them.
 
-#### Use `preload` instead of `includes`
+##### Use `preload` instead of `includes`
 
 The `includes` and `preload` methods in Rails are both ways to avoid an N+1
 query. The `includes` method in Rails uses a heuristic approach to determine
@@ -149,7 +172,7 @@ allows you to avoid the join, while still avoiding the N+1 query.
 You can see a real example of this solution being used in
 <https://gitlab.com/gitlab-org/gitlab/-/merge_requests/67655>.
 
-#### De-normalize some foreign key to the table
+##### De-normalize some foreign key to the table
 
 De-normalization refers to adding redundant precomputed (duplicated) data to
 a table to simplify certain queries or to improve performance. In this
@@ -202,7 +225,7 @@ You can see this approach implemented in
 <https://gitlab.com/gitlab-org/gitlab/-/merge_requests/66963> . This MR also
 de-normalizes `pipeline_id` to fix a similar query.
 
-#### De-normalize into an extra table
+##### De-normalize into an extra table
 
 Sometimes the previous de-normalization (adding an extra column) doesn't work for
 your specific case. This may be due to the fact that your data is not 1:1, or
@@ -249,7 +272,7 @@ logic to delete these rows if or whenever necessary in your domain.
 Finally, this de-normalization and new query also improves performance because
 it does less joins and needs less filtering.
 
-#### Use `disable_joins` for `has_one` or `has_many` `through:` relations
+##### Use `disable_joins` for `has_one` or `has_many` `through:` relations
 
 Sometimes a join query is caused by using `has_one ... through:` or `has_many
 ... through:` across tables that span the different databases. These joins
@@ -365,3 +388,27 @@ end
 
 You can see a real example of using this method for fixing a cross-join in
 <https://gitlab.com/gitlab-org/gitlab/-/merge_requests/67655>.
+
+#### Allowlist for existing cross-joins
+
+A cross-join across databases can be explicitly allowed by wrapping the code in the
+`::Gitlab::Database.allow_cross_joins_across_databases` helper method.
+
+This method should only be used:
+
+- For existing code.
+- If the code is required to help migrate away from a cross-join. For example,
+  in a migration that backfills data for future use to remove a cross-join.
+
+The `allow_cross_joins_across_databases` helper method can be used as follows:
+
+```ruby
+::Gitlab::Database.allow_cross_joins_across_databases(url: 'https://gitlab.com/gitlab-org/gitlab/-/issues/336590') do
+  subject.perform(1, 4)
+end
+```
+
+The `url` parameter should point to an issue with a milestone for when we intend
+to fix the cross-join. If the cross-join is being used in a migration, we do not
+need to fix the code. See <https://gitlab.com/gitlab-org/gitlab/-/issues/340017>
+for more details.
diff --git a/doc/user/admin_area/moderate_users.md b/doc/user/admin_area/moderate_users.md
index 6697f233463..d093f0058c2 100644
--- a/doc/user/admin_area/moderate_users.md
+++ b/doc/user/admin_area/moderate_users.md
@@ -153,6 +153,9 @@ For the deactivation option to be visible to an admin, the user:
 NOTE:
 Users can also be deactivated using the [GitLab API](../../api/users.md#deactivate-user).
 
+NOTE:
+Users can be notified about account deactivation if [user deactivation emails](settings/email.md#enable-user-deactivation-emails) are enabled.
+
 ### Automatically deactivate dormant users
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/320875) in GitLab 14.0.
diff --git a/doc/user/admin_area/settings/email.md b/doc/user/admin_area/settings/email.md
index 98481b1d8e0..ad4291cbe26 100644
--- a/doc/user/admin_area/settings/email.md
+++ b/doc/user/admin_area/settings/email.md
@@ -72,6 +72,18 @@ To add additional text to emails:
 1. Enter your text in the **Additional text** field.
 1. Select **Save changes**.
 
+## Enable user deactivation emails **(FREE SELF)**
+
+GitLab can send email notifications to users when their account has been deactivated.
+
+To enable these notifications:
+
+1. On the top bar, select **Menu > Admin**.
+1. On the left sidebar, select **Settings > Preferences** (`/admin/application_settings/preferences`).
+1. Expand **Email**.
+1. Select **Enable user deactivation emails**.
+1. Select **Save changes**.
+
 <!-- ## Troubleshooting
 
 Include any troubleshooting steps that you can foresee. If you know beforehand what issues
diff --git a/doc/user/group/saml_sso/index.md b/doc/user/group/saml_sso/index.md
index ac06de14481..18b0cdbbd63 100644
--- a/doc/user/group/saml_sso/index.md
+++ b/doc/user/group/saml_sso/index.md
@@ -120,12 +120,13 @@ SSO has the following effects when enabled:
 - Users must be signed-in through SSO before they can pull images using the [Dependency Proxy](../../packages/dependency_proxy/index.md).
 <!-- Add bullet for API activity when https://gitlab.com/gitlab-org/gitlab/-/issues/9152 is complete -->
 
-Notes:
+When SSO is enforced, users are not immediately revoked. If the user:
 
-- When SSO is enforced users are not immediately revoked
-- If they are signed out then they cannot access the group after being removed from the identity provider
-- However, if the user has an active session they can continue accessing the group for up to 24 hours, until the identity provider session times out
-- Upon SCIM update, the user's access would be immediately revoked
+- Is signed out, they cannot access the group after being removed from the identity provider.
+- Has an active session, they can continue accessing the group for up to 24 hours until the identity
+  provider session times out.
+
+When SCIM updates, the user's access is immediately revoked.
 
 ## Providers
 
@@ -288,7 +289,7 @@ If a user is already a member of the group, linking the SAML identity does not c
 
 ### Blocking access
 
-Please refer to [Blocking access via SCiM](scim_setup.md#blocking-access).
+Please refer to [Blocking access via SCIM](scim_setup.md#blocking-access).
 
 ### Unlinking accounts
 
diff --git a/doc/user/group/saml_sso/scim_setup.md b/doc/user/group/saml_sso/scim_setup.md
index bb6d238d991..5e90501d487 100644
--- a/doc/user/group/saml_sso/scim_setup.md
+++ b/doc/user/group/saml_sso/scim_setup.md
@@ -58,8 +58,10 @@ During this configuration, note the following:
 - The `Tenant URL` and `secret token` are the ones retrieved in the
   [previous step](#gitlab-configuration).
 - It is recommended to set a notification email and check the **Send an email notification when a failure occurs** checkbox.
-- For mappings, we will only leave `Synchronize Azure Active Directory Users to AppName` enabled.
-  - `Synchronize Azure Active Directory Groups to AppName` should be disabled. However, this does not mean Azure AD users cannot be provisioned in groups. Leaving it enabled does not break the SCIM user provisioning, but causes errors in Azure AD that may be confusing and misleading.
+- For mappings, we only leave `Synchronize Azure Active Directory Users to AppName` enabled.
+  `Synchronize Azure Active Directory Groups to AppName` is usually disabled. However, this
+  does not mean Azure AD users cannot be provisioned in groups. Leaving it enabled does not break
+  the SCIM user provisioning, but causes errors in Azure AD that may be confusing and misleading.
 
 You can then test the connection by clicking on **Test Connection**. If the connection is successful, be sure to save your configuration before moving on. See below for [troubleshooting](#troubleshooting).
 
@@ -163,10 +165,11 @@ graph TD
   B -->|Yes| D[GitLab sends message back 'Email exists']
 ```
 
-During provisioning, note the following:
+During provisioning:
 
 - Both primary and secondary emails are considered when checking whether a GitLab user account exists.
-- Duplicate usernames are also handled, by adding suffix `1` upon user creation. E.g. due to already existing `test_user` username, `test_user1` is used).
+- Duplicate usernames are also handled, by adding suffix `1` upon user creation. For example,
+  due to already existing `test_user` username, `test_user1` is used.
 
 As long as [Group SAML](index.md) has been configured, existing GitLab.com users can link to their accounts in one of the following ways:
 
@@ -189,9 +192,9 @@ For role information, please see the [Group SAML page](index.md#user-access-and-
 
 ### Blocking access
 
-To rescind access to the top-level group and all sub-groups and projects remove or deactivate the user on the identity provider.
-SCIM providers will generally update GitLab with the changes on-demand, which is minutes at most.
-The user's membership is revoked and they immediately lose access.
+To rescind access to the top-level group, all sub-groups, and projects, remove or deactivate the user
+on the identity provider. SCIM providers generally update GitLab with the changes on demand, which
+is minutes at most. The user's membership is revoked and they immediately lose access.
 
 NOTE:
 Deprovisioning does not delete the GitLab user account.