diff options
| -rw-r--r-- | doc/development/contributing/issue_workflow.md | 4 | ||||
| -rw-r--r-- | doc/user/group/subgroups/index.md | 32 |
2 files changed, 19 insertions, 17 deletions
diff --git a/doc/development/contributing/issue_workflow.md b/doc/development/contributing/issue_workflow.md index 7ba8e3dce95..fed29d37b26 100644 --- a/doc/development/contributing/issue_workflow.md +++ b/doc/development/contributing/issue_workflow.md @@ -177,7 +177,7 @@ If you've decided that you would like to work on an issue, please @-mention the [appropriate product manager](https://about.gitlab.com/handbook/product/#who-to-talk-to-for-what) as soon as possible. The product manager will then pull in appropriate GitLab team members to further discuss scope, design, and technical considerations. This will -ensure that that your contribution is aligned with the GitLab product and minimize +ensure that your contribution is aligned with the GitLab product and minimize any rework and delay in getting it merged into master. GitLab team members who apply the ~"Accepting Merge Requests" label to an issue @@ -226,7 +226,7 @@ code snippet right after your description in a new line: `~"feature proposal"`. Please keep feature proposals as small and simple as possible, complex ones might be edited to make them small and simple. -Please submit Feature Proposals using the ['Feature Proposal' issue template](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/.gitlab/issue_templates/Feature%20Proposal.md) provided on the issue tracker. +Please submit Feature Proposals using the ['Feature Proposal' issue template](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/.gitlab/issue_templates/Feature%20proposal.md) provided on the issue tracker. For changes in the interface, it is helpful to include a mockup. Issues that add to, or change, the interface should be given the ~"UX" label. This will allow the UX team to provide input and guidance. You may diff --git a/doc/user/group/subgroups/index.md b/doc/user/group/subgroups/index.md index b55946a788f..8db36c4a0e8 100644 --- a/doc/user/group/subgroups/index.md +++ b/doc/user/group/subgroups/index.md @@ -1,9 +1,8 @@ # Subgroups -> **Notes:** -> - [Introduced][ce-2772] in GitLab 9.0. -> - Not available when using MySQL as external database (support removed in -> GitLab 9.3 [due to performance reasons][issue]). +NOTE: **Note:** +[Introduced][ce-2772] in GitLab 9.0. Not available when using MySQL as external +database (support removed in GitLab 9.3 [due to performance reasons][issue]). With subgroups (aka nested groups or hierarchical groups) you can have up to 20 levels of nested groups, which among other things can help you to: @@ -79,14 +78,14 @@ structure. ## Creating a subgroup -> **Notes:** -> - You need to be an Owner of a group in order to be able to create -> a subgroup. For more information check the [permissions table][permissions]. -> - For a list of words that are not allowed to be used as group names see the -> [reserved names][reserved]. -> - Users can always create subgroups if they are explicitly added as an Owner to -> a parent group even if group creation is disabled by an administrator in their -> settings. +NOTE: **Note:** +You need to be an Owner of a group in order to be able to create a subgroup. For +more information check the [permissions table][permissions]. +For a list of words that are not allowed to be used as group names see the +[reserved names][reserved]. +Users can always create subgroups if they are explicitly added as an Owner to +a parent group even if group creation is disabled by an administrator in their +settings. To create a subgroup: @@ -136,12 +135,15 @@ From the image above, we can deduct the following things: ### Overriding the ancestor group membership ->**Note:** +NOTE: **Note:** You need to be an Owner of a group in order to be able to add members to it. +NOTE: **Note:** +A user's permissions in a subgroup cannot be lower than in any of its ancestor groups. +Therefore, you cannot reduce a user's permissions in a subgroup with respect to its ancestor groups. + To override a user's membership of an ancestor group (the first group they were -added to), simply add the user in the new subgroup again, but with different -permissions. +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 permissions, then they will inherit those permissions in every other subgroup |