When a project is created the default permissions are the following:
We have chosen to let authenticated users see the project in the dashboard and explore metrics in order to show to the Inria community that developers follow good practices. We expect il will motivate users to do their best.
Of course the administrators of a project can always change this default behaviour in the Administration, Permissions panel of their project. For instance, one can remove the ability to any authenticated user to browse the project metrics. To do so, just uncheck Browse for sonar-users.
The project can also be made public to let any visitor see metrics and the source code, see the Administration, Permissions panel.
A project administer can add an user to a project. In the project page, go to the Administration tab then choose the Permissions section. Then search a user and specify the project-level permissions. Remember that only Inria members who have once connected to the SonarQubeTM plateform will be visible.
The personal token is used to authenticate to the SonarQubeTM server when a user wants to publish analysis results.
Recall the procedure to create a token:
This token will be useful to authenticate to the instance replacing authentication with the login/password pair. It will be used for example as a secret variable on Gitlab or Jenkins, or directly stored on the machine performing analysis and tests (e.g. virtual machine).
Notice the token is per user, not per project. It is not supposed to be publicly available. Of course to automatize analysis in a CI (continuous integration) process one token will be used on some machines shared by administrators of the CI. It means you trust your collaborators of the CI project. As soon as you leave the project or if you don't trust your collaborators anymore you should revoke the personal token you used for this project. An advice: an Inria permanent member should create the personal token to avoid updating the token too often. In addition, one personal token per project should be created so that one can revoke a token related to a specific project without loosing the permission to publish reports on other projects.
This personal token sharing seems to be a weakness since several people can publish results in the name of one user. This is true. But it is the way SonarQubeTM works... A solution could be to create some additional SonarQubeTM accounts, one per project, to create non personal tokens. We don't want to come to that because:
this is a lot of additional administrative tasks (creation/destruction of fake accounts),
this solution just shift the problem. Several people may have access to the project's SonarQubeTM account and add/revoke tokens so that the authenticity problem remains the same.