Simplify and improve the separation of duty process for the review of issues

Hello everyone,

Separation of duty is a good best practice and for some fields it is required (e.g. by law or regulation). In general a programmer shall not be the (only) reviewer of his own code.

What is the status quo?
At the moment this can be achieved by giving some users the role: Administer Issues. Only users with this permission are allowed to change the type and severity of issues, resolve issues as being Won’t Fix or False Positive. But if you want to rely on the SonarQube workflow and use it to support your review process, then users with the Administer Issues role should not write code, because they are able to close issues caused by their own code.

What are you trying to accomplish?
A developer shall not be able to resolve issues caused by his own code as being Won’t Fix or False Positive. Even if the developer is an Administer for Issues.

Why does this matter to you?
We work in a field that requires separation of duty. Maybe there are some companies out there with a team of developers who only write code and a team of dedicated reviewers who only review the issues and never write their own code, but for us this is not very practical. Who wants to review code only? It is fine to give a couple of senior programmers the role Administer Issues, but these senior programmers should also be able to write code without having to manually track what he or she is now allowed to review.

How would that look in SonarQube? Alternatives?
With the automatic issue assignment feature SonarQube can already detect who is the author of the code. That is great, don’t change that! Please implement an optional feature that does not allow the author to change issue type and severity, resolve issue as being Won’t Fix or False Positive of his own code. Don’t change anything else.

Why should it be a priority now?
I think it fits the DNA of SonarQube. It can ensure agile development and a flat hierarchy. Even if you don’t care and every programmer has the Administer Issues permission, because you don’t like fixed role models. At least you would be able to ensure that a second person looks at the issue if it should be resolved with Won’t Fix or False Positive as a minimum measure.

I fount this post, they have a very strict separation of duty with developers and analyzers. This is something we want to avoid because it does not really empower developers:

And this is the response from sonarsource to that post:

Please give the idea a thought.Thanks,

1 Like