Skip to content

The value of the`lock_memberships_to_ldap` setting should not affect authorizations refresh

Manoj M J requested to merge mmj-auth-refresh-lock_memberships_to_ldap into master

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.

Edited by Manoj M J

Merge request reports