Using permission templates makes no sense without a naming scheme.
I strongly advise to use one combined with permission templates, everything else will be a maintenance nightmare.
If you’re using LDAP based authentication and group mapping (the same group name in AD and Sonarqube), a user will get member of the related Sonarqube group after login.
With api/permissions/add_group and parameters permission and projectid it should be possible to give a Sonarqube group access for a project, but i never used it.
yes.
From my experience, it’s best to use AD groups (one admin group, one read all group,1…n developer groups) combined with permission templates - works like a charm.
But this requires a naming scheme.
In general automation only works with (naming) conventions and rules.
If your Jenkins user has sufficient permissions, a sonarqube project is automatically created.
Our Jenkins user has admin permissions, because we have to create the project with
special settings (new code setting, name of the main branch … etc.) via web api.
You might use a similar approach, see
Gilbert