How to change the type of a Rule? E.g. from Bug to Code smell


I am using SonarQube version 6.5. I have a requirement in my project where I need to modify some of the default rules. I copied the default Sonar Way Quality Profile and assigned my project to it.

I am able to deactivate the rules as per my requirement and change its severity by going to that specific Rule -> Quality Profiles -> Change/Deactivate
But I also need to change the type of some of the rules from Bug to Code Smells. I am not able to find a way to do this.

Please suggest.


1 Like

Hi @swati.jasuja,

There are two ways which completely depends on your requirements. First if you want to change before analyzing the code then you have to edit the plugin for this for ex: SonarJava( you can locate the rules with their respective RSPEC key(in this case it is S100) and change the type to CODE_SMELLS. After that you need to package the plugin and create the jar file and then put that into sonarqube server plugin directory and restart the sonarqube.

Another way is after analyzation if you want to change the type then in Sonarqube UI go to that issue and then you can change from bug to code_smells or as per requirement but again while adopting this approach you have to do for every issue.

I hope you got the answer then don’t forget to like.:sunglasses:

1 Like

Thanks Vicky for the reply.

I am very new to SonarQube and the server setup is also not done by me. I am just using the sonarscanner on my local machine to analyze my code and need to update the rules as per the architect’s suggestions. I do not have access to Sonarqube server and not sure if I can do what you have suggested regarding plugins.

Could you please share some more insight or maybe some link where I can get more information about how to get the plugin for a particular rule. This rule is part of a custom Quality Profile that I have created and need it to be implemented whenever the analysis runs on my code.

Thanks for your help.


As Vicky alluded, there’s no easy way to change the rule type, and that’s on purpose. You could fork the plugin of interest, edit the code and re-package, but then you have to do that for each new plugin version, rather than being able to just benefit from the work of others. In all, this is really not a recommended solution.

Far better, to tell your architect that rule types are immutable - because within the UI they are.


To complement @ganncamp answer (that indeed the type of a rule cannot be modified in SonarQube, as it is tightly coupled to what the rule actually checks as per its specification, and is set by the analyzer which defines/implements this rule):

Also note that once an Issue is raised by a specific Rule, then the type of that specific Issue can be changed by the user. That is because SonarQube acknowledges the fact that based on project-specific context (and/or following human review), user may wish to indicate that (for example) bug occurs in a security-critical part of the application, and may therefore pose a security threat in that context.

Thanks all for your answers.

I understand that it is not possible to change the rule type so that the same is implemented while the scan runs, without changing the plugins.

Just to gather more information, is there any link or documentation where I can get more information about how to get the plugin for a particular rule? Does this way of updating the plugin code work for rules in Quality Profiles that are copied from the default profile?


Going backward from a rule to its plugin actually requires a small amount of detective work. The Rules page has a Repository facet. You can think of repositories as rule groups. Typically each plugin has only one, altho I have seen community plugins with multiple repositories. Conversely, it is also possible for a plugin to contribute to a repository it didn’t declare, altho again that’s rare.

However, the primary case is a 1-to-1 relationship between repository and plugin. Repository membership isn’t reflected on the rule detail page, but if you choose a repository in the Rules page facet, you’ll see only rules in that repository. So then once you’ve figured out which repository a rule comes from, you need to trace it back to the providing plugin. Here, naming conventions come into play. “Sonar Analyzer [Language]” repositories are provided by SonarSource’s analyzers, so “SonarAnalyer Java” comes from SonarJava, and so on. The repositories from other plugins are generally named to tie them very transparently to their plugins.


1 Like

Aside of the rules/repositories technicalities, I have to say that I would very strongly advice against modifying a plugin you do not own for the sole purpose of changing a rule type to comply to a requirement.

The current type-based model has been thoughtfully designed into what it currently is, and I believe any requirement to change the rule type should first be challenged to understand what is the underlying reasoning. I would then expect this actual reasoning to be discussed here.


Thank you everyone for your inputs.

Agree with many of your points and seems like changing the type of rule is not a good idea. I will get back to my architect with these details.


1 Like


As you suggested that I can get the plugin from the rules repository and I was able to figure out that the rules that I am referring to are from the SonarTSQL plugin, but can you help me find out where can I get the actual code of these rules?

As @vicky suggested that I can go to to find my plugin, but when I search there, I do not see any plugin with the name sonarTSQL. What I get is sonar-tsql-plugin which is present at How would I know whether this is the one that contains rules that I am using on my SonarQube? Because as I traverse through all the folders, I do not find any files that contain the rules that I currently see on my sonarQube. Can you please guide me here?



SonarTSQL is closed-source. You’re not going to be able to get the code.


Thanks Ann.

If that is the case, what does it mean when the previous answers in this chain mention I can “edit the plugin” and even “locate the rules with their respective RSPEC key”?

It means that I assumed we were talking about SonarJava or one of the other open source analyzers.

If not edit, is there any way that I can add custom rules for TSQL language that I can use for my project?

Sorry, custom rules aren’t supported for TSQL.

Similar to above issue , I am analyzing python projects with SOnar qube. For testing I introduced a code/syntax bug but because of its default type - issue is reported as code smell and not Bug.

I created a new quality profile inheriting default profile with parser rule activated. Issue is reported in code smell.
Can you please suggest why/how we can change issue type to BUG from code smell - if anything has changed since last comment.