SonarQube 7.1 Issues Permissions

SonarQube
1

I am looking for a solution to separate the permissions at the level of SonarQube issues.

The scenario is as follow:

There are two different teams: Development and QA and a single project where the teams are assigned to.

User stories

As a Product Developer, I should not be able to resolve or close any SonarQube Issues so that I can push forward with a deployment

As a QA Team member, I should only be able to resolve or close SonarQube issues so that deployments are still controlled and validated.

Acceptance Criteria

GIVEN that I am a product developer
WHEN I update issues in sonar qube
THEN I should not be able to close issues raised

GIVEN that I am a QA Team member
WHEN I update issues in Sonar qube
THEN I should be able to close issues raised on behalf of Product developers

Q. There is anyone who knows a possible resolution for the scenario mentioned?

SonarQube Version: 7.1

2

Hi,

The Administer Issues permission is what you’re looking for. As described in the docs

Change the type and severity of issues, resolve issues as being “Won’t Fix” or “False Positive” (users also need “Browse” permission).

However. that doesn’t leave any updates for your developers except comment and assignment, but maybe that’s enough.

 
HTH,
Ann

3

Hey,

@ganncamp thank you for your reply. It does not help me.

I need a permission that completely restrict developers to mark issues as resolved. They should not be able to see the {Resolve as fixed, Resolve as false positive, Resolve as won’t fix} options.

The QA team has Administer Issues permission set up. They are able to mark an issues as fixed.

4

Hi,

If you don’t want developers to mark issues resolved, then don’t give them the Administer Issues permission.

 
Ann

5

Hey

If the developers will have only browse permission, they will be able to mark issues as fixed as well. :expressionless: Devs_without_Administer_Issues_Permission

I’ve added an image with the view that a developer has. I mention that the developers have browse permission, because the project is set up as private and without this permission, they are not allowed to see the project.

6

Hi,

I understand the confusion now. “Resolve as fixed” is a temporary marker to say “I’ve worked on the code and I believe the next analysis will Close this issue”. But it’s not a permanent marker; and the next analysis will actually Reopen the issue if it hasn’t actually been fixed.

Unfortunately, with the introduction of Live Measures a couple versions ago, this resolution does have an immediate impact on issue counts and therefore potentially the Quality Gate, but those impacts only last until the next analysis.

There’s no permission that controls access to this action because it’s not permanent. Also, we have plans to remove the action, altho I can’t give you an ETA on that.

 
Ann

7

Thanks a lot @ganncamp for you input.