Add latest changes from gitlab-org/gitlab@master

4 files changed, 32 insertions, 13 deletions

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.