Hi,
checked the sonarqube productboard https://portal.productboard.com/sonarsource/3-sonarqube,
but found only one related entry
https://portal.productboard.com/sonarsource/3-sonarqube/c/157-improve-permissions-templating
So i’ve created a new proposal with this content
We use Sonarqube Enterprise and recently started using Sonarqube project tags.
What is missing is an additional project tag next to the project key regex - as we are used to from portfolios - when creating permission templates.
Use case = there are projects that need to run with the old namespace/project key for some reasons, but some of them are transferred to other teams. This means we need to adjust the permissions, which is error proned to impossible with just a regex against the Sonarqube project key.
As i’m not sure how actively the productboard is really used, i did an addtional post here.
Gilbert
Hi @Rebse ,
Thank you for raising this here and in ProductBoard. We do actively use Productboard but there is no harm in posting here as well. Would you be interested in a short call to talk through your needs in a bit more detail?
John
Hi John,
unfortunately I am completely booked shortly before vacation, and i have only the use case i mentioned.
There are projects with a namespace like com.foo.bar (groupid, maven projects).
The permission template (we make good use of permission templates) has regex com\.foo\.bar.+
In a number of these projects, the responsible teams changed.
For one reason or another, they are not able to change the groupid right now / maybe never,
means the regex ain’t an option anymore.
But we’re are forced to split the permissions nevertheless NOW / ASAP.
So, the only convinient option would be to tag those projects and use permission templates
with projects tags - as we’re used from portfolios.
Our developers are used to tags from Jira … etc. and they started to use them in Sonarqube also.
The support of using Sonarqube project tags for specific settings should be expanded.
Gilbert
Hi @anon67236913 ,
Thank you for this additional detail, we will discuss this.
John