Add latest changes from gitlab-org/gitlab@master

10 files changed, 50 insertions, 7 deletions

diff --git a/doc/ci/img/collapsible_log.png b/doc/ci/img/collapsible_log.png
deleted file mode 100644
index 088928ddede..00000000000
--- a/doc/ci/img/collapsible_log.png
+++ /dev/null
diff --git a/doc/ci/img/collapsible_log_v12_6.png b/doc/ci/img/collapsible_log_v12_6.png
new file mode 100644
index 00000000000..294421c645d
--- /dev/null
+++ b/doc/ci/img/collapsible_log_v12_6.png
diff --git a/doc/ci/pipelines.md b/doc/ci/pipelines.md
index 4538d1e7849..d1e50039417 100644
--- a/doc/ci/pipelines.md
+++ b/doc/ci/pipelines.md
@@ -157,7 +157,7 @@ In the following example:
 - Two sections are collapsed and can be expanded.
 - Three sections are expanded and can be collapsed.
 
-![Collapsible sections](img/collapsible_log.png)
+![Collapsible sections](img/collapsible_log_v12_6.png)
 
 ## Configuring pipelines
 
diff --git a/doc/development/background_migrations.md b/doc/development/background_migrations.md
index 0a08360b727..5e16f83b63c 100644
--- a/doc/development/background_migrations.md
+++ b/doc/development/background_migrations.md
@@ -16,10 +16,15 @@ migrations automatically reschedule themselves for a later point in time.
 > the migrations.
 
 In the vast majority of cases you will want to use a regular Rails migration
-instead. Background migrations should _only_ be used when migrating _data_ in
+instead. Background migrations should be used when migrating _data_ in
 tables that have so many rows this process would take hours when performed in a
 regular Rails migration.
 
+Background migrations _may_ also be used when executing numerous single-row queries
+for every item on a large dataset. Typically, for single-record patterns, runtime is
+largely dependent on the size of the dataset, hence it should be split accordingly
+and put into background migrations.
+
 Background migrations _may not_ be used to perform schema migrations, they
 should only be used for data migrations.
 
diff --git a/doc/development/database_review.md b/doc/development/database_review.md
index 38785897361..b1c3ed47976 100644
--- a/doc/development/database_review.md
+++ b/doc/development/database_review.md
@@ -103,10 +103,13 @@ and details for a database reviewer:
     need to fit comfortably within `15s` - preferably much less than that - on GitLab.com.
   - For column removals, make sure the column has been [ignored in a previous release](what_requires_downtime.md#dropping-columns)
 - Check [background migrations](background_migrations.md):
-  - Establish a time estimate for execution on GitLab.com.
-  - They should only be used when migrating data in larger tables.
-    - If a single `update` is below than `1s` the query can be placed
+  - Establish a time estimate for execution on GitLab.com. For historical purposes,
+    it's highly recommended to include this estimation on the merge request description.
+  - If a single `update` is below than `1s` the query can be placed
       directly in a regular migration (inside `db/migrate`).
+  - Background migrations are normally used, but not limited to:
+    - Migrating data in larger tables.
+    - Making numerous SQL queries per record in a dataset.
   - Review queries (for example, make sure batch sizes are fine)
   - Because execution time can be longer than for a regular migration,
     it's suggested to treat background migrations as post migrations:
diff --git a/doc/user/group/subgroups/img/group_members_filter_v12_6.png b/doc/user/group/subgroups/img/group_members_filter_v12_6.png
new file mode 100644
index 00000000000..0207515ded0
--- /dev/null
+++ b/doc/user/group/subgroups/img/group_members_filter_v12_6.png
diff --git a/doc/user/group/subgroups/index.md b/doc/user/group/subgroups/index.md
index 52b7035389a..997cb1ba6c5 100644
--- a/doc/user/group/subgroups/index.md
+++ b/doc/user/group/subgroups/index.md
@@ -4,7 +4,7 @@ type: reference, howto, concepts
 
 # Subgroups
 
->[Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/2772) in GitLab 9.0.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/2772) in GitLab 9.0.
 
 Subgroups, also known as nested groups or hierarchical groups, allow you to have up to 20
 levels of groups.
@@ -142,6 +142,16 @@ From the image above, we can deduce the following things:
 - Administrator is the Owner and member of **all** subgroups and for that reason,
   as with User3, there is no indication of an ancestor group.
 
+[From](https://gitlab.com/gitlab-org/gitlab/issues/21727) GitLab 12.6, you can filter
+this list using dropdown on the right side:
+
+![Group members filter](img/group_members_filter_v12_6.png)
+
+- **Show only direct members** displays only Administrator and User3, since these are
+  the only users that belong to group `four`, which is the one we're inspecting.
+- **Show only inherited members** displays User0, User1 and User2, no matter which group
+  above the hierarchy is the source of inherited permissions.
+
 ### Overriding the ancestor group membership
 
 NOTE: **Note:**
@@ -186,7 +196,7 @@ Here's a list of what you can't do with subgroups:
 
 [ce-2772]: https://gitlab.com/gitlab-org/gitlab-foss/issues/2772
 [permissions]: ../../permissions.md#group-members-permissions
-[reserved]:  ../../reserved_names.md
+[reserved]: ../../reserved_names.md
 [issue]: https://gitlab.com/gitlab-org/gitlab-foss/issues/30472#note_27747600
 
 <!-- ## Troubleshooting
diff --git a/doc/user/project/members/img/project_members.png b/doc/user/project/members/img/project_members.png
new file mode 100644
index 00000000000..5d44b5d957e
--- /dev/null
+++ b/doc/user/project/members/img/project_members.png
diff --git a/doc/user/project/members/img/project_members_filter_v12_6.png b/doc/user/project/members/img/project_members_filter_v12_6.png
new file mode 100644
index 00000000000..0207515ded0
--- /dev/null
+++ b/doc/user/project/members/img/project_members_filter_v12_6.png
diff --git a/doc/user/project/members/index.md b/doc/user/project/members/index.md
index 2f8394eb104..c069882e38f 100644
--- a/doc/user/project/members/index.md
+++ b/doc/user/project/members/index.md
@@ -10,6 +10,31 @@ or import a new user to your project.
 To view, edit, add, and remove project's members, go to your
 project's **Settings > Members**.
 
+## Inherited membership
+
+When your project belongs to the group, group members inherit the membership and permission
+level for the project from the group.
+
+![Project members page](img/project_members.png)
+
+From the image above, we can deduce the following things:
+
+- There are 3 members that have access to the project.
+- User0 is a Reporter and has inherited their permissions from group `demo`
+  which contains current project.
+- For User1 there is no indication of a group, therefore they belong directly
+  to the project we're inspecting.
+- Administrator is the Owner and member of **all** groups and for that reason,
+  there is an indication of an ancestor group and inherited Owner permissions.
+
+[From](https://gitlab.com/gitlab-org/gitlab/issues/21727), you can filter this list
+using dropdown on the right side:
+
+![Project members filter](img/project_members_filter_v12_6.png)
+
+- **Show only direct members** displays only User1.
+- **Show only inherited members** displays User0 and Administrator.
+
 ## Add a user
 
 Right next to **People**, start typing the name or username of the user you