Add latest changes from gitlab-org/gitlab@13-8-stable-ee

4 files changed, 38 insertions, 7 deletions

diff --git a/doc/administration/geo/setup/database.md b/doc/administration/geo/setup/database.md
index 6e2ddfb812c..95f67b20ab5 100644
--- a/doc/administration/geo/setup/database.md
+++ b/doc/administration/geo/setup/database.md
@@ -634,6 +634,20 @@ For each Patroni instance on the secondary site:
 to `gitlab.rb` where `<slot_name>` is the name of the replication slot for your Geo secondary. This will ensure that Patroni recognizes the replication slot as permanent and will not drop it upon restarting.
 1. If database replication to the secondary was paused before migration, resume replication once Patroni is confirmed working on the primary.
 
+## Migrating a single PostgreSQL node to Patroni
+
+Before the introduction of Patroni, Geo had no Omnibus support for HA setups on the secondary node.
+
+With Patroni it's now possible to support that. In order to migrate the existing PostgreSQL to Patroni:
+
+1. Make sure you have a Consul cluster setup on the secondary (similar to how you set it up on the primary).
+1. [Configure a permanent replication slot](#step-1-configure-patroni-permanent-replication-slot-on-the-primary-site).
+1. [Configure a Standby Cluster](#step-2-configure-a-standby-cluster-on-the-secondary-site)
+   on that single node machine.
+   
+You will end up with a "Standby Cluster" with a single node. That allows you to later on add additional patroni nodes
+by following the same instructions above.
+
 ## Troubleshooting
 
 Read the [troubleshooting document](../replication/troubleshooting.md).
diff --git a/doc/user/profile/notifications.md b/doc/user/profile/notifications.md
index 38ef01b7537..ae672d8414f 100644
--- a/doc/user/profile/notifications.md
+++ b/doc/user/profile/notifications.md
@@ -149,6 +149,7 @@ Users are notified of the following events:
 | Password changed by administrator | User           | Security email, always sent when an administrator changes the password of another user |
 | Two-factor authentication disabled | User          | Security email, always sent. |
 | New user created             | User                | Sent on user creation, except for OmniAuth (LDAP)|
+| New SAML/SCIM user provisioned. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/276018) in GitLab 13.8  | User            | Sent when a user is provisioned through SAML/SCIM |
 | User added to project        | User                | Sent when user is added to project |
 | Project access level changed | User                | Sent when user project access level is changed |
 | User added to group          | User                | Sent when user is added to group |
diff --git a/doc/user/project/merge_requests/getting_started.md b/doc/user/project/merge_requests/getting_started.md
index bc718ae867f..dc5e1f81a63 100644
--- a/doc/user/project/merge_requests/getting_started.md
+++ b/doc/user/project/merge_requests/getting_started.md
@@ -161,7 +161,7 @@ Feature.disable(:merge_request_reviewers)
 Feature.disable(:merge_request_reviewers, Project.find(<project id>))
 ```
 
-#### Reviewer approval rules
+#### Approval Rule information for Reviewers **(STARTER)**
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/233736) in GitLab 13.8.
 > - It was [deployed behind a feature flag](../../../user/feature_flags.md), disabled by default.
@@ -169,11 +169,15 @@ Feature.disable(:merge_request_reviewers, Project.find(<project id>))
 > - It's enabled on GitLab.com.
 > - It's recommended for production use.
 > - It can be enabled or disabled for a single project.
-> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-reviewer-approval-rules). **(CORE ONLY)**
+> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-approval-rule-information-for-reviewers). **(STARTER ONLY)**
 
-When editing the **Reviewers** field in a new or existing merge request, this feature
+WARNING:
+This feature might not be available to you. Check the **version history** note above for details.
+
+When editing the **Reviewers** field in a new or existing merge request, GitLab
 displays the name of the matching [approval rule](merge_request_approvals.md#approval-rules)
-below the name of each suggested reviewer. [Code Owners](../code_owners.md) are displayed as `Codeowner` without group detail. We intend to iterate on this feature in future releases.
+below the name of each suggested reviewer. [Code Owners](../code_owners.md) are displayed as **Code Owner** without group detail.
+We intend to iterate on this feature in future releases.
 
 This example shows reviewers and approval rules when creating a new merge request:
 
@@ -183,7 +187,7 @@ This example shows reviewers and approval rules in a merge request sidebar:
 
 ![Reviewer approval rules in sidebar](img/reviewer_approval_rules_sidebar_v13_8.png)
 
-##### Enable or disable Reviewer Approval Rules **(CORE ONLY)**
+##### Enable or disable Approval Rule information for Reviewers **(STARTER ONLY)**
 
 Merge Request Reviewers is under development and ready for production use.
 It is deployed behind a feature flag that is **enabled by default**.
diff --git a/doc/user/project/merge_requests/merge_request_approvals.md b/doc/user/project/merge_requests/merge_request_approvals.md
index 01de98edeac..887f563be51 100644
--- a/doc/user/project/merge_requests/merge_request_approvals.md
+++ b/doc/user/project/merge_requests/merge_request_approvals.md
@@ -164,8 +164,15 @@ To add or edit the default merge request approval rule:
      the rule.
 1. Click **Add approval rule** or **Update approval rule**.
 
-Any merge requests that were created before changing the rules will not be changed.
-They will keep the original approval rules, unless manually [overridden](#editing--overriding-approval-rules-per-merge-request).
+When [approval rule overrides](#prevent-overriding-default-approvals) are allowed,
+changes to these default rules will **not** be applied to existing merge
+requests, except for changes to the [target branch](#scoped-to-protected-branch) of
+the rule.
+
+When approval rule overrides are not allowed, all changes to these default rules
+will be applied to existing merge requests. Any approval rules that had previously been
+manually [overridden](#editing--overriding-approval-rules-per-merge-request) during a
+period when approval rule overrides where allowed, will not be modified.
 
 NOTE:
 If a merge request targets a different project, such as from a fork to the upstream project,
@@ -252,6 +259,11 @@ one of the following is possible:
 
   ![Remove approval](img/remove_approval.png)
 
+When [approval rule overrides](#prevent-overriding-default-approvals) are allowed,
+changes to default approval rules will **not** be applied to existing
+merge requests, except for changes to the [target branch](#scoped-to-protected-branch)
+of the rule.
+
 NOTE:
 The merge request author is not allowed to approve their own merge request if
 [**Prevent author approval**](#allowing-merge-request-authors-to-approve-their-own-merge-requests)