Group-level permissions: SonarQube synchronizes permissions based on group membership rather than individual project settings
SonarQube doesn’t support 1:1 synchronization with GitLab groups - user has to manually add the groups to synchronize permissions
In my opinion, it should pull all top groups (those without a parent group) from GitLab if the group list in Sonar is empty or radio-button choice: full sync or list groups.
Sonar pulls groups from GitLab - what does Sonar use them fo r?
According to my observations, the user sync mechanism works like in the following way:
3.1. Sonar pulls projects for specified groups and sub gro ups.
3.2. It lists users from projects (but only those directly in the project - it doesn’t include users with group-level acc ess).
3.3 If I have a user assigned only to GitLab groups, the user isn’t created on the Sonar side - they must be assigned to at least one project that is in a group from the list of groups to synchronize.
3.4 What permissions are assigned to this user? From the project or from the group? Users can have different permissions at the project and group level in GitLab.
Users with the sonarqube-admins group should be automatically provisioned in the user’s directory.
Sonarqube-admins should have minimum browse permissions in all projects.
Sync is automatic
In version 2025.5 there was no option “Allow all groups” only Allowed groups selected manually - the sync permissions worked well for indicated groups. Inconvinience is that we have to add groups manually. Here in this case sonar-administrators was sonar local group
Now in version 2026.03 there is a new option “Allow all groups”. This option automatically take all groups from gitlab but also “sonar-administrators” and this is the problem. It destroys the administration because this imported group does not have any permissions on project level.
In our opinion sonar-administrators group shouldn’t be sync with gitlab because we cannot properly administrate the permissions like “Project-Execute analysis” or there should be a specific mapping for that group.
We want to apply the scenario that a person that is sonar administrstor is not the administrator of gitlab.
So your locally-created administrators group is now being wiped away by automatic provisioning?
Why is it not practical for you to manage that membership on the GitLab side? The idea here is that with automatic provisioning you have one place to manage all the permissions and don’t have to jump back and forth to do that.