Admin access to a recreated SonarQube project is revoked

With SonarQube 8.9, it appears that when a project is deleted and then re-created with the same project key, admin access to the project is turned off by default. You have to manually “Restore access” to the project under Administration > Projects > Management.

However, restoring access doesn’t seem to actually fully restore access. We have a service that runs and manages the PR decoration settings on projects, and for projects that we have to restore access to, the API calls to set the PR decoration settings fails with the error

Unknown HTTP request error: {"errors":[{"msg":"Insufficient privileges"}]}

Other projects that we have not had to restore access to are able to successfully make the API call (for reference the endpoint is /alm_settings/set_github_binding).

Why does a recreated project have revoked admin permissions by default? Is there a way to configure this or an API endpoint to restore the access? And why does restoring access not seem to fully allow settings changes via the API?


To be clear, you’re not resurrecting the project. You’re creating a project from scratch that coincidentally has the same name and key as a deleted project. Nothing is remembered, so nothing can be ‘revoked’.

So you’ll need to treat “re-created” projects just like brand new projects, following all the same steps and granting all the same privileges.


Hi Ann,

We only run into the issue I described above (having to manually “Restore access” and even after doing so, getting the “Insufficient privileges” error when making the PR decoration setting API call) when a project happens to have the same project key as one that was previously deleted. We haven’t seen this issue in projects whose project key has never existed in our instance before.

If there is nothing “remembering” project keys that have been deleted and then created again, why do we have to Restore access to projects that fall into this category? We integrate with GitHub Actions, so all SonarQube projects are created the same way through our workflows.

Also I’d still love answers to my other questions – is there an API endpoint for restoring access? Why does restoring access not seem to fully allow access to the project again (in the case of the insufficient privledges for API calls)? And what is restoring access actually doing?


Okay, so can you please be explicit about what it means to ‘manually “Restore access”’ and exactly where you see

A screenshot would be fabulous, if you have one…


Here’s an example of a project that was created via a Pull Request scan. I am logged in as admin, but I don’t see the “Project Settings” tab (it should be next to Project Information).

I also get a 403 Forbidden when trying to make API calls on the settings for this project (the example below is calling the /alm_setting/set_github_binding endpoint)

When I go to Administration > Projects > Management, there is a “Restore Access” button for this project.



After I click that, I have access to the Project Settings again.

And I’m able to call the alm_settings/set_github_binding endpoint.

So the issue at hand is likely more to do with projects that have only had a PR scan and not a scan on the default branch. It appears that admin access to the project is not enabled by default when a project has only had a PR scan, and we have to manually “Restore access” in order to access the project’s settings and make API calls on the settings of the project.


Thanks for drawing me a picture! :smiley:

I’m out of my depth at this point & have referred the thread for more expert attention.