Hi! For security reasons our organization do not wish to give the default user groupoå browsing rights to private projects. But, from what I understand that browse permission also determine whether or not a user sees a project when he/she tries to add it to their portfolio. So the consequnec is that a user that has Administer permission to a portfolio but not browse rights to projects per default, can’t find and add projects to his or her portfolio. Am I doing something wrong or is their anyway to accomplish this that makes the projects show up in a search to add them to a portfolio (Edit definition) but not show up in the regular “Projects” listing?
Must-share information (formatted with Markdown):
- which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)
Enterprise Edition, Version 8.9.2 (build 46101)
- what are you trying to achieve
Let administrators of portfolios add projects without giving them browsing rights to those projects
- what have you tried so far to achieve this
Editing project permissions and portfolio permissions
An idea, which is also a question - Is it possible to relatively easy, without messing up other permissions, add “Browse” permission to all projects for a specific user/group? That could be a good compromise.
Welcome to the community!
You’re not doing anything wrong. This is how it works. Either a user can see/Browse a project, or she can’t.
It just doen’t work this way, and it’s not clear to my why you would want portfolio admins see a project within a portfolio but not see it directly. Or are your admins creating portfolios on behalf of others? In that case, it’s worth pointing out that you could grant Portfolio creation rights to the folks who are the audience for Portfolios.
And yes, it would definitely work to give a subgroup Browse rights on your projects. They would then be able to not just browse the projects but also add them to Portfolios.
You haven’t said how you’re handling authentication / authorization, but it’s worth pointing out that if you’re delegating authentication & using group mapping, the group will need to exist in your external source of truth.
SEC over here in my organization have issues with sonar-users being able to browse all projects, that is why users in general don’t have that permission. Our portfolios however are public and we have a couple of users that help build those portfolios by manually adding projects to them. These users have Administer permissions to the portfolio but they don’t have Browse permissions to all projects, and thus not all projects show up when they try to search for them to add in Edit definition.
My idea is to create a new group, something like “Portfolio_admins” that I can give the Browse Permission to all projects. At least then the access to all projects is limited in scope. There’s another question there about adding permissions to multiple projects en masse, but I opened a separate thread for that - so that’s probably gonna be resolved shortly: Give a new group permission to existing projects - SonarQube - Sonar Community (sonarsource.com)
Thanks for sharing!
Yes, this will absolutely work. And I want to point out the effects of not all projects in a Portfolio being Browsable by its users.
As an example, here’s a portfolio of all projects on our internal dogfooding instance. The metrics are pre-calculated against all projects in the Portfolio, but project lists are dynamic. Here’s what it looks like for me logged in (with global admin rights):
And here it is anonymous: