### Summary There are two related problems observed: 1. Despite being a member of a shared group, member shows up with incorrect/lower permission in the member list. 1. The effective role permission seems to take effect for projects within the group, but not the group itself. That is, if a member should have 'maintainer' due to shared groups, they are unable to create a project in the group, but they do have maintainer permission on projects within the group. ### Steps to reproduce 1. Create a group (eg. `Fake Company/RBAC/Maintainers`) 1. Add some users to the `Maintainers` group 1. Create another group (eg. `Fake Company/Fake Team`) 1. Add the `Maintainers` group to the members of `Fake Team` with "Maintainer" permissions 1. Users in the `Maintainers` group will _not_ be able to create projects or sub-groups ### Example Project (If possible, please create an example project here on GitLab.com that exhibits the problematic behavior, and link to it here in the bug report) (If you are using an older version of GitLab, this will also determine whether the bug is fixed in a more recent version) ### What is the current *bug* behavior? Permissions gained through group membership take effect in all sub-groups and projects, but not within the group itself that the permissions were applied too. ### What is the expected *correct* behavior? Permissions should take effect at the top-level group AND below. Also ideally, the user member list should update to reflect these higher permissions (to remove the inconsistency). ### Relevant logs and/or screenshots ### Output of checks #### GitLab environment info GitLab.com ### Possible fixes /cc @dblessing @ifarkas