Abiliy to disable resolving issues manually in the UI

Problem: My company needs the option to be able to disable managing the lifecycle of Sonar issues in the UI. They would rather ask everyone to resolve or ignore issues in the code repository. Could you please provide us that setting? I think that security exceptions may have to be exceptions to this, as security issues more often cannot be fixed by providing better code, but of course, if we can resolve them too in the code, all the better. Please note though we don’t like “// NOSONAR”, because it makes all issues ignored, and when that is the only thing that works for a language, it has a serious downside over resolving issues in the UI, which we don’t want to risk. We just want to ignore one specific issue at a time, but in the code. And preferably in a readable way, i.e., not at the end of the line. For example, ESLint supports “// eslint-disable-next-line” comments.

Reasoning: For years my company has been using SonarQube (hosted server) in a way that Sonar issues have always been resolved in the code. We told projects that if they see an issue as a false positive or they would want to resolve it as a won’t fix, mark it with a comment or in case of Java they could also do with a SuppressWarnings annotation, but never use the SonarQube UI for resolving issues, otherwise they risk the chance that in case of a database wipe or project deletion, all the issues will reappear again. Okay, this is not likely with backups also created regularly, I get it. Maybe it is more likely that certain corner cases like merging branches, changing code may cause certain issues to reappear again, or testing in different environments, or in case the project would move to the cloud. Regardless, we had a good reason to say, issues should be resolved in the code. This way we indeed did not depend on any services, the issue management was self-contained in the code, just like with any other linter tools like ESLint, etc., and it worked reliably.

And we could ask developers for this discipline so far, until a new Bitbucket addon has entered the “game”: https://marketplace.atlassian.com/apps/1212735/include-code-quality-for-bitbucket?tab=overview&hosting=datacenter . This addon also provides convenient buttons to resolve issues, assign them, etc. Now we have a bigger worry that developers will want to use them, it’s like now the temptation is even bigger, as the buttons for issue lifecycle management are shown in the pull request. Yes, we could ask devs not to use those buttons, but the point is that the buttons are much closer to their reach, and they might press them anyway. Yes we could also ask the Bitbucket addon developer to provide us the same feature we request here, but most likely we’ll be forwarded to the root of the problem, as the addon only mirrors what Sonar does too, or more accurately: what Sonar doesn’t let us do, in this case.

Hey there.

Two points:

  • You can make sure that no users are granted the Administer Issues permission at a project-levle, effectively disabling the ability to resolve through the UI. I have to assume this is something that the Bitbucket plugin respects. If not… :person_shrugging:
  • We understand the feedback around being able to use NOSONAR on a specific rule and we have some plans on this in the medium-term

Can you explain why?

Sorry, Colin, I forgot to respond.

Can you explain why?

As I wrote above, “otherwise they risk the chance that in case of a database wipe or project deletion, all the issues will reappear again. […] or in case the project would move to the cloud.”

You can make sure that no users are granted the Administer Issues permission at a project-levle

While that is true, the problem is the security issues that we still need to resolve somehow. Because of the potential of too many false positives for those, like hundreds in a larger project, a lot of NOSONAR comments would pollute the code too much, whereas the rest of the issue types can easily be corrected in the code, with a manageable number of NOSONAR exceptions. So we think security issues should be allowed to be resolved in the GUI. At the same time, I understand that this is kind of a mixed bag, where resolution of security issues through the UI would still not survive e.g., a switch from self-hosted SonarQube to SonarCloud, but we have no better strategy to use yet.

To correct myself, I mean security hotspots. (Not to be confused with vulnerability issues, but I used the wrong terminology.)

Hello Krisztian,

Thank you for your feedback.

I understand that you would like your developers to be able to keep the won’t fix/false positive status information in the code rather than SonarQube UI/DB. This is mainly because you are afraid to lose this information in case of a DB wipe or other internal project operations.

Today, we cannot deactivate UI usage/DB storage for issues status as this is the base for all SonarQube functionalities (activity, reports…).

However, we plan to enhance the //NOSONAR feature and allow it to accept a list of rule keys as parameters to precise the list of issues to ignore in one given line (today you can already use //NOSONAR on one line but it will ignore all issues on that line).

Would this help you solve your problem?

Also, you mentioned that the bitbucket addon is practical because it provides quick buttons to assign a status to an issue. Did you try using SonarLint?

Thanks, @Ilham, the //NOSONAR enhancement is already a huge improvement in my opinion, and I very much appreciate it. However, if I have to be honest, then it’s just part of the overall solution my workplace is looking for, as we would also like to have the ability to disallow resolving regular issues in the Sonar UI in favor of resolving or ignoring as much as we can in the code repository. At the same time, I do understand that your user base is much larger than just us, and if there are more important features to add…

you mentioned that the bitbucket addon is practical because it provides quick buttons to assign a status to an issue

Actually what I said was that we don’t want to allow the use of such buttons, the only exception is security hotspots.

Yes, we do use SonarLint for IntelliJ IDEA, although as far as I know, it is not as precise as a full PR analysis (one thing I do remember right now is, it does not look into our Gradle build configuration for rule exclusions), and developers can make mistakes, so the annotation of issues in a pull request is still useful, we could say it’s a necessary “next line of defense”.

Hello Krisztian,

Thank you for your feedback.

Could you please help us understand better the pain points you have with SonarQube that make you wanna set issues status in the code?

You mentioned 2 possible ways of losing issues status data:

  • Database and project deletion: The database can be backed up, so I guess that is not the real issue.
  • Corner cases like merging branches, changing code, testing in different environments, project move to the cloud… Could you please describe those cases more in detail and give us some examples? That would help us tackle those points.

Thanks in advance.