<!--- Please read this! Before opening a new issue, make sure to search for keywords in the issues filtered by the "regression" or "bug" label. For the Community Edition issue tracker: - https://gitlab.com/gitlab-org/gitlab-ce/issues?label_name%5B%5D=regression - https://gitlab.com/gitlab-org/gitlab-ce/issues?label_name%5B%5D=bug For the Enterprise Edition issue tracker: - https://gitlab.com/gitlab-org/gitlab-ee/issues?label_name%5B%5D=regression - https://gitlab.com/gitlab-org/gitlab-ee/issues?label_name%5B%5D=bug and verify the issue you're about to submit isn't a duplicate. ---> ### Summary The access level displayed on Project Members page is taken from the parent group, even though the actual level is inherited/overridden from a sub-group. This is misleading and can lead to incorrect security audits. ### Steps to reproduce 1) Create a new group and add a user as a reporter 2) Add a new repo to the group and confirm the users access level is as expected 3) Create a new sub-group and add the original user as a developer 4) Share the repo to the sub group with developer access level 5) Confirm that the user can now write to this repo 6) Observe access displayed on project members page is inconsistent with actual access level. ### Example Project - Project: https://gitlab.com/access-levels-parent/access-ghosting - Parent group: https://gitlab.com/access-levels-parent - Sub-group: https://gitlab.com/access-levels-parent/access-levels-sub ### What is the current *bug* behavior? Access level displayed on Project page is that of the parent group ### What is the expected *correct* behavior? Highest level of access inherited ### Relevant logs and/or screenshots 1) Add Adam as reporter to parent group  2) Add Adam as developer to sub group  3) Level reported on project page is misleading - Adam actually has developer access to this repo  ### Output of checks This bug happens on GitLab.com