Specify "immediate parent group" as appropriate

doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md

@@ -461,7 +461,7 @@ group = Group.find_by_path_or_name("groupname")
 # Count users from subgroup and up (inherited)
 group.members_with_parents.count
 
-# Count users from parent group and down (specific grants)
+# Count users from the parent group and down (specific grants)
 parent.members_with_descendants.count
 ```
 

doc/api/groups.md

@@ -122,7 +122,7 @@ Parameters:
 
 | Attribute                | Type              | Required | Description |
 | ------------------------ | ----------------- | -------- | ----------- |
-| `id`                     | integer/string    | yes      | The ID or [URL-encoded path of the group](README.md#namespaced-path-encoding) of the parent group |
+| `id`                     | integer/string    | yes      | The ID or [URL-encoded path of the group](README.md#namespaced-path-encoding) of the immediate parent group |
 | `skip_groups`            | array of integers | no       | Skip the group IDs passed |
 | `all_available`          | boolean           | no       | Show all the groups you have access to (defaults to `false` for authenticated users, `true` for admin); Attributes `owned` and `min_access_level` have precedence |
 | `search`                 | string            | no       | Return the list of authorized groups matching the search criteria |

doc/development/permissions.md

@@ -55,10 +55,10 @@ levels are available (defined in the `Gitlab::Access` module):
 - Maintainer (`40`)
 - Owner (`50`)
 
-If a user is the member of both a project and the project parent group, the
+If a user is the member of both a project and the project parent group(s), the
 higher permission is taken into account for the project.
 
-If a user is the member of a project, but not the parent group (or groups), they
+If a user is the member of a project, but not the parent group(s), they
 can still view the groups and their entities (like epics).
 
 Project membership (where the group membership is already taken into account)

doc/public_access/public_access.md

@@ -59,7 +59,7 @@ it. The restriction for visibility levels on the application setting level also
 applies to groups, so if that's set to internal, the explore page will be empty
 for anonymous users. The group page now has a visibility level icon.
 
-Admin users cannot create subgroups or projects with higher visibility level than that of the parent group.
+Admin users cannot create subgroups or projects with higher visibility level than that of the immediate parent group.
 
 ## Visibility of users
 

doc/user/group/epics/manage_epics.md

@@ -229,7 +229,7 @@ To move an issue to another epic:
 > - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/37081) to [GitLab Premium](https://about.gitlab.com/pricing/) in 12.8.
 
 If you have the necessary [permissions](../../permissions.md) to close an issue and create an
-epic in the parent group, you can promote an issue to an epic with the `/promote`
+epic in the immediate parent group, you can promote an issue to an epic with the `/promote`
 [quick action](../../project/quick_actions.md#quick-actions-for-issues-merge-requests-and-epics).
 Only issues from projects that are in groups can be promoted. When attempting to promote a confidential
 issue, a warning will display. Promoting a confidential issue to an epic will make all information

doc/user/group/index.md

@@ -31,7 +31,7 @@ Each group on the **Groups** page is listed with:
 
 - How many subgroups it has.
 - How many projects it contains.
-- How many members the group has, not including members inherited from parent groups.
+- How many members the group has, not including members inherited from parent group(s).
 - The group's visibility.
 - A link to the group's settings, if you have sufficient permissions.
 - A link to leave the group, if you are a member.
@@ -397,7 +397,7 @@ When transferring groups, note:
 - Changing a group's parent can have unintended side effects. See [Redirects when changing repository paths](../project/index.md#redirects-when-changing-repository-paths).
 - You can only transfer groups to groups you manage.
 - You must update your local repositories to point to the new location.
-- If the parent group's visibility is lower than the group's current visibility, visibility levels for subgroups and projects will change to match the new parent group's visibility.
+- If the immediate parent group's visibility is lower than the group's current visibility, visibility levels for subgroups and projects will change to match the new parent group's visibility.
 - Only explicit group membership is transferred, not inherited membership. If the group's owners have only inherited membership, this leaves the group without an owner. In this case, the user transferring the group becomes the group's owner.
 
 ## Group settings
@@ -571,9 +571,9 @@ You can only choose projects in the group as the template source.
 This includes projects shared with the group, but it **excludes** projects in
 subgroups or parent groups of the group being configured.
 
-You can configure this feature for both subgroups and parent groups. A project
+You can configure this feature for both subgroups and immediate parent groups. A project
 in a subgroup will have access to the templates for that subgroup, as well as
-any parent groups.
+any immediate parent groups.
 
 ![Group file template dropdown](img/group_file_template_dropdown.png)
 

doc/user/group/saml_sso/index.md

@@ -215,7 +215,7 @@ On subsequent visits, you should be able to go [sign in to GitLab.com with SAML]
 
 ### Role
 
-The first time you sign in, GitLab adds you to the parent group with the Guest role. Existing members with appropriate privileges can promote that new user.
+The first time you sign in, GitLab adds you to the top-level parent group with the Guest role. Existing members with appropriate privileges can promote that new user.
 
 If a user is already a member of the group, linking the SAML identity does not change their role.
 

doc/user/group/subgroups/index.md

@@ -25,7 +25,7 @@ For more information on allowed permissions in groups and projects, see
 ## Overview
 
 A group can have many subgroups inside it, and at the same time a group can have
-only 1 parent group. It resembles a directory behavior or a nested items list:
+only one immediate parent group. It resembles a directory behavior or a nested items list:
 
 - Group 1
   - Group 1.1
@@ -89,7 +89,7 @@ of words that are not allowed to be used as group names see the
 [reserved names](../../reserved_names.md).
 
 Users can always create subgroups if they are explicitly added as an Owner (or
-Maintainer, if that setting is enabled) to a parent group, even if group
+Maintainer, if that setting is enabled) to an immediate parent group, even if group
 creation is disabled by an administrator in their settings.
 
 To create a subgroup:
@@ -99,9 +99,9 @@ To create a subgroup:
 
    ![Subgroups page](img/create_subgroup_button.png)
 
-1. Create a new group like you would normally do. Notice that the parent group
+1. Create a new group like you would normally do. Notice that the immediate parent group
    namespace is fixed under **Group path**. The visibility level can differ from
-   the parent group.
+   the immediate parent group.
 
    ![Subgroups page](img/create_new_group.png)
 
@@ -113,12 +113,13 @@ 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. This model allows access to nested groups if you
+level from the parent group(s). This model allows access to nested groups 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. This means secrets configured for the parent group are available to subgroup jobs.
+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.
 
-In addition, maintainers of projects that belong to subgroups can see the details of Runners registered to parent groups.
+In addition, maintainers of projects that belong to subgroups can see the details of Runners registered to parent group(s).
 
 The group permissions for a member can be changed only by Owners, and only on
 the **Members** page of the group the member was added.

doc/user/permissions.md

@@ -283,7 +283,7 @@ group.
 ### Subgroup permissions
 
 When you add a member to a subgroup, they inherit the membership and
-permission level from the parent group. This model allows access to
+permission level from the parent group(s). This model allows access to
 nested groups if you have membership in one of its parents.
 
 To learn more, read through the documentation on

doc/user/project/labels.md

@@ -54,7 +54,7 @@ and edit labels.
 
 View the project labels list by going to the project and clicking **Issues > Labels**.
 The list includes all labels that are defined at the project level, as well as all
-labels inherited from the parent group. You can filter the list by entering a search
+labels inherited from the immediate parent group. You can filter the list by entering a search
 query at the top and clicking search (**{search}**).
 
 To create a new project label: