Currently, activating a rule in a quality profile generates issues/hotspots for all the instances of that rule in the code on the next scan. We can then mark individual cases false positive or won’t fix or safe, but we can’t do that until the scan has been done, which raises the issue counts, which then needs to be explained.
It would be useful to have an option, when activating a rule, to have all instances of that rule found in the first scan go into a new state, called PENDING, for instance. PENDING issues, unlike OPEN issues, would not add to overall counts. However, any new instances of that rule found on any subsequent scan (e.g., due to code added after the first post-activation scan) would go to the normal OPEN state. Meanwhile, we can at our convenience look over the PENDING issues and either confirm them or close them. PENDING rules, unlike FIXED rules, would never disappear.
I should clarify the last sentence: I mean that issues in the PENDING state don’t disappear.
In case it helps, what you could do is Bulk Change issues to ‘Fixed’. That takes them out of the metrics that count Open issues, and give you a little window to do review. Any issues still in Fixed would be moved back to Open automatically at the next analysis.
Well yeah, there are workarounds, but they aren’t as elegant as the proposed feature. Also, bulk change is not available for hotspots, so a bunch of individual changes are needed, and that’s very slow.
I thought of another instance where the PENDING state would be useful. There are many new rules that are basically, “there’s this new feature which you should be using” (such as java:S2148). So we don’t want our old code to get dinged for not using a feature that didn’t exist when it was written, but we’d still like NEW code to get dinged, have it show up in SonarLint, etc. (Our group’s policy is that developers only have to fix smells in old methods if they modify those methods.)