Add documentation for filtering and sorting group members

Added to document new filtered search bar

doc/user/group/index.md

@@ -211,6 +211,88 @@ To remove a member from a group:
 1. (Optional) Select the **Also unassign this user from related issues and merge requests** checkbox.
 1. Click **Remove member**.
+## Filter and sort members in a group
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/21727) in GitLab 12.6.
+> - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/228675) in GitLab 13.7.
+> - Improvements are [deployed behind a feature flag](../feature_flags.md), enabled by default.
+> - Improvements are enabled on GitLab.com.
+> - Improvements are recommended for production use.
+> - For GitLab self-managed instances, GitLab administrators can opt to [disable improvements](#enable-or-disable-improvements-to-the-ability-to-filter-and-sort-group-members). **(CORE ONLY)**
+
+The following sections illustrate how you can filter and sort members in a group. To view these options,
+navigate to your desired group, go to **Members**, and include the noted search terms.
+
+### Membership filter
+
+By default, inherited and direct members are displayed. The [membership](subgroups/index.md#membership) filter can be used to display only inherited or only direct members.
+
+#### Only display inherited members
+
+Include `Membership` `=` `Inherited` in the search text box.
+
+![Group members filter inherited](img/group_members_filter_inherited_13_7.png)
+
+#### Only display direct members
+
+Include `Membership` `=` `Direct` in the search text box.
+
+![Group members filter direct](img/group_members_filter_direct_13_7.png)
+
+### 2FA filter
+
+[Owner](../permissions.md#group-members-permissions) permissions required.
+
+By default, members with 2FA enabled and disabled are displayed. The 2FA filter can be used to display only members with 2FA enabled or only members with 2FA disabled.
+
+#### Only display members with 2FA enabled
+
+Include `2FA` `=` `Enabled` in the search text box.
+
+![Group members filter 2FA enabled](img/group_members_filter_2fa_enabled_13_7.png)
+
+#### Only display members with 2FA disabled
+
+Include `2FA` `=` `Disabled` in the search text box.
+
+![Group members filter 2FA disabled](img/group_members_filter_2fa_disabled_13_7.png)
+
+### Search
+
+You can search for members by name, username, or email.
+
+![Group members search](img/group_members_search_13_7.png)
+
+### Sort
+
+You can sort members by **Account**, **Access granted**, **Max role**, or **Last sign-in** in ascending or descending order.
+
+![Group members sort](img/group_members_sort_13_7.png)
+
+### Enable or disable improvements to the ability to filter and sort group members **(CORE ONLY)**
+
+Group member filtering and sorting improvements are deployed behind a feature flag that is **enabled by default**.
+[GitLab administrators with access to the GitLab Rails console](../../administration/feature_flags.md)
+can opt to disable the improvements.
+
+To disable them:
+
+```ruby
+# For the instance
+Feature.disable(:group_members_filtered_search)
+# For a single group
+Feature.disable(:group_members_filtered_search, Group.find(<group id>))
+```
+
+To enable them:
+
+```ruby
+# For the instance
+Feature.enable(:group_members_filtered_search)
+# For a single group
+Feature.enable(:group_members_filtered_search, Group.find(<group id>))
+```
+
 ## Changing the default branch protection of a group
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/7583) in GitLab 12.9.

doc/user/group/subgroups/index.md

@@ -116,9 +116,9 @@ Follow the same process to create any subsequent groups.
 ## Membership
-When you add a member to a subgroup, they inherit the membership and permission
-level from the parent group(s). This model allows access to nested groups if you
-have membership in one of its parents.
+When you add a member to a group, that member is also added to all subgroups.
+Permission level is inherited from the group’s parent. This model allows access to 
+subgroups if you have membership in one of its parents.
 Jobs for pipelines in subgroups can use [runners](../../../ci/runners/README.md) registered to the parent group(s).
 This means secrets configured for the parent group are available to subgroup jobs.
@@ -131,31 +131,23 @@ the **Members** page of the group the member was added.
 You can tell if a member has inherited the permissions from a parent group by
 looking at the group's **Members** page.
-![Group members page](img/group_members.png)
+![Group members page](img/group_members_13_7.png)
 From the image above, we can deduce the following things:
 - There are 5 members that have access to the group `four`.
-- User0 is a Reporter and has inherited their permissions from group `one`
+- User 0 is a Reporter and has inherited their permissions from group `one`
   which is above the hierarchy of group `four`.
-- User1 is a Developer and has inherited their permissions from group
+- User 1 is a Developer and has inherited their permissions from group
   `one/two` which is above the hierarchy of group `four`.
-- User2 is a Developer and has inherited their permissions from group
+- User 2 is a Developer and has inherited their permissions from group
   `one/two/three` which is above the hierarchy of group `four`.
-- For User3 there is no indication of a parent group, therefore they belong to
+- For User 3 the **Source** column indicates **Direct member**, therefore they belong to
   group `four`, the one we're inspecting.
 - 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.
+  as with User 3, the **Source** column indicates **Direct member**.
+Members can be [filtered by inherited or direct membership](../index.md#membership-filter).
 ### Overriding the ancestor group membership
@@ -169,9 +161,9 @@ Therefore, you cannot reduce a user's permissions in a subgroup with respect to
 To override a user's membership of an ancestor group (the first group they were
 added to), add the user to the new subgroup again with a higher set of permissions.
-For example, if User0 was first added to group `group-1/group-1-1` with Developer
+For example, if User 1 was first added to group `one/two` with Developer
 permissions, then they inherit those permissions in every other subgroup
-of `group-1/group-1-1`. To give them Maintainer access to `group-1/group-1-1/group1-1-1`,
+of `one/two`. To give them Maintainer access to group `one/two/three/four`,
 you would add them again in that group as Maintainer. Removing them from that group,
 the permissions fall back to those of the ancestor group.

doc/user/permissions.md

@@ -289,6 +289,7 @@ group.
 | View Value Stream analytics                            | ✓     | ✓        | ✓         | ✓          | ✓     |
 | View Billing **(FREE ONLY)**                           |       |          |           |            | ✓ (4) |
 | View Usage Quotas **(FREE ONLY)**                      |       |          |           |            | ✓ (4) |
+| Filter members by 2FA status                           |       |          |           |            | ✓     |
 1. Groups can be set to [allow either Owners or Owners and
   Maintainers to create subgroups](group/subgroups/index.md#creating-a-subgroup)