Membership requests are taken into account for access level validation
Summary
Membership requests are taken into account for inviting new members.
Steps to reproduce
- Have a group without LDAP sync
- A user requests membership as Developer (Access level 30)
- We enable LDAP sync membership for this group, but this user is not added with any LDAP group
- We create a subproject on this group, and try to add the same user with Reporter (Access level 20)
- An error will appear complaining about Reporter (20) < Developer (30)
It seems that the membership request and its access level it still taken into account, even if they are no longer accessible when enabling LDAP sync.
The current workaround is to temporarily disable the LDAP sync on the parent group, remove deny the access requests and re-enable the LDAP sync configuration as it was.
Example Project
Cannot provide one, it is EE only.
What is the current bug behavior?
We cannot add a member with a lower permission than what he/she requested before enablind LDAP on the group.
`Access level should be greater than or equal to Developer inherited membership from group %{group_name}"
The current workaround is to temporarily disable the LDAP sync on the parent group, remove/deny the access requests and re-enable the LDAP sync configuration as it was. Disabling Allow users to request access
on the group options does not change this behaviour.
What is the expected correct behavior?
Requested memberships and their levels should not be taken into account
Possible fixes
Probably related to highest_group_member
method:
- https://gitlab.com/gitlab-org/gitlab-ee/blob/master/app/models/group.rb#L396
- https://gitlab.com/gitlab-org/gitlab-ee/blob/master/app/models/member.rb#L375 (If you can, link to the line of code that might be responsible for the problem)
Related to https://gitlab.com/gitlab-org/gitlab-ee/issues/9613
Running on 11.11.3-ee