I am using SonarLint on IntelliJ but I feel this feature request makes sense for all platforms.
Severity based Filtering (and or Grouping) on Issues
When we do “Analyze all project files”, usually we get a big list of issues to address(grouped file-wise).
It would be great to have a filter (and grouping) based on severity (Blocker / Critical / Major / Minor) like we have it on the SonarQube.
This feature would be really helpful as usually people address issues severity-wise, like Blockers first, then critical and so on.
So such a filter (or grouping) would help spot and the issues.
Looking forward for this simple yet useful feature 
Best Regards,
Ram
Hello @Ramakrishna_Punjal and welcome to the Sonar community forum!
I’ve taken note of your feedback. We’re currently in the process of sorting out how SonarLint can better help developers apply the Clean as You Code principles - once this is done we’ll be in a better position to fine-tune the issue presentation and to better consider your feedback.
How do you currently address the issues found by SonarQube in your branch or pull request? Do you always address the highest-severity issues first?
I am wondering whether you are already aware of Clean as You Code and in this case if there is anything preventing you from addressing issues in New Code first in SonarQube.
1 Like
I’ll jump in to provide some context which I think is common from most people asking for this:
(and something I think is missed in the many times, over many years, that I’ve seen someone suggest the solution is to adopt “clean as you code” )
I fully embrace the “Clean as you Code” philosophy, but the ground reality is that it is quite common for any significantly sized company working to improve their CI/CD pipeline by setting up (and paying for) SonarQube… will pick an arbitrary ruleset that the developer has no control over, then define minimum acceptable thresholds as KPI for them to feel happy about measuring and report to upper management, then set Sonar loose to run on a 10-year old project with 5k files… which suddenly highlights all it’s flaws. That’s not necessarily a bad thing, except the council declares an edict such as: All Blocker/Critical items must be fixed in 30 days, all medium in 90 days… etc.
In these large projects we maintain, many of the files haven’t been touched in years, and have no current need to be looked at except to fix these reported issues. The quality gates might be focusing only on ‘new code’ but the there is still a need for us to be able to filter on “Blocker” and “Critical” “Bugs” and “Vulnerabilities”. Sure, as we touch those files we will embrace the “clean as you code” mantra and fix other things we find, but we need a way to prioritize and quickly focus on items that will quickly improve the ratings for Reliability, Security, Maintainability, etc… I fully understand “Clean as you Code” ensures it all new code is clean, and the codebase will gradually improve over time (1Y=20%, 2Y=35%, 5Y=50% according to your marketing), and that “Handling the code quality of your entire codebase is disruptive overwhelming” but anybody using these results for KPIs are going to leverage it to force results on the entire codebase, and isn’t going to wait 5Y for that. Despite the guidance to just “clean as you code”, it is still being used to force cleaning of everything.
I saw it suggested somewhere to look at the SonarQube web project for the file list , but then you need to copy the filename and switch back to the IDE to find it one-at-a-time. This really needs to be built-into the IDE to make it seamless.
Hi @strangelookingnerd
Thanks for the effort here, we really appreciate it.
As I replied on the PR, we don’t plan to add a filtering system in the IDE because it would go against the Clean As You Code methodology and more specifically the promotion of solving every issue in your code. Maybe another way to see it would be to group the issues by severity but I don’t know if your problem would be solved.
We really appreciate your effort here and we will let you know if some change of priorities happens in the future.
Best
Alexander