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”: Include Code Quality for Bitbucket | Atlassian Marketplace . 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?