The value of the`lock_memberships_to_ldap` setting should not affect authorizations refresh
What does this MR do and why?
This MR aims at fixing the issue mentioned in https://gitlab.com/gitlab-org/gitlab/-/issues/341572. Please see this issue for more detailed information.
TL;DR:
Until a while ago, the only way to refresh authorizations was thru the service Gitlab::ProjectAuthorizations
, which did not care about the value of Gitlab::CurrentSettings.lock_memberships_to_ldap?
while refreshing authorizations that arose from existing project-group shares
.
Later, new services were introduced that refreshes authorizations in a different way internally, while providing the same result. These services uses Projects::Members::EffectiveAccessLevelFinder
under the hood to refresh authorizations.
Here too, we should have not cared about the value of Gitlab::CurrentSettings.lock_memberships_to_ldap?
while refreshing authorizations, but due to the project.allowed_to_share_with_group?
method we used in this service, this turned out to be not the case, in EE installations.
Which means that, we now have a discrepancy between these 2 ways of refreshing authorizations - which is problematic. We should make sure that these 2 ways should return the same result (even though the way they process this refresh internally is different).
So, this MR makes sure that these 2 ways of refreshing authorizations behave the same way, so that they provide the same output.
Screenshots or screen recordings
How to set up and validate locally
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.