You cannot have group mapping via LDAP and manage (for example) the sonarqube-admin group solely in Sonarqube-Database.
The sonarqube-admin group has to be created/maintained in LDAP or else the user who was added to “sonarqube-admin” group will be removed from the group because it is not found in the users list of LDAP groups.
In the last days i saw someone asking why his admin-rights were taken away overnight … and i myself had the same experience and not yet the time to look into it.
The reason for this was the assumption that you can give administrative access to multiple users by creating a group (for sonar-admins for example) and configuring users into that group.
We did not realize/understand that this does not work when the Feature of “Group Mapping” is active … because - if i understand correctly - with active LDAP Group Mapping, the only authority on users in a group is the configured “group-mapping-provider”.
And this means: the user i added to the group “sonar-admin” logs off and at the time she logs on again, her group-configuration is read from provider … and if there is no group “sonar-admin” then the user will be removed from the sonar-admin group.
So i need to put every group i want to configure for usage into the provider (e.g. LDAP) … i cannot create a group “strawberryenthusiasts” in SQ-Database whose users are only managed in Sonarqube, because when such a user logs on the next time … this group “strawberryenthusiasts” is NOT existing in the provider (LDAP) and thus … the user will be no “strawberryenthusiast” any more.
So there is no flexibility … if i want my users to automagically get sorted into the LDAP supplied Groups … i cannot “enhance” this mapping with sonarqube-internal additional groups.
Is this something that you are considering for a change? In my perspective this constraint is a chosen decision … which might be opened for a change. Or are there are already good reasons agains such flexibility?
@Colin colin, if you are able, please repost your reply here, too, tyvm!