I have a question to Issue Backdating: https://docs.sonarqube.org/latest/user-guide/issues/#header-4
- existing project
- using SCM (svn)
- rule is old in the profile (not added or activated)
- source code is not new (was not changed in the last leak period)
- reading an external report with issues
Because of a bug in our external tool the report was empty and all issues were closed. After external tool was working again same issues has been forwarded to SQ. The issues are in “new code” now? Because no new rule and within old code my expectation would be that SQ show them in overall section and not in new code?
Jumping to the issues in “new code” there are issues in source code areas which are not new (yellow). This is not logical for me?
What’s your SonarQube version? For non-external issues with a recent SQ version I’d have expected them to be re-opened, preserving history and dates. But honestly with external issues I’m not sure.
we are still using SQ 6.7 LTS. Is this improved in SQ 7.9 LTS?
8.1 docu is saying:
If the date of the last change to the line is available (this requires SCM integration) then under certain circumstances, the issue will be backdated:
- On first analysis of a project or branch
- When the rule is new in the profile (a brand new rule activated or a rule that was deactivated and is now activated)
- When the analyzer has just been upgraded (because rule implementations could be smarter now)
- When the rule is external
Wondering why you not just say “New Issues” could be only in “New Code”. That would mean “New Issues” would be always only in yellow marked areas in all views?
Yes, issue backdating improved markedly in 7.9.
Because that’s not true. As a trivial example, if I remove the only use of a private method, that (old) method will have a new issue about an unused private method. Similarly, if I remove the null-check before an old dereference, the potential NPE issues is still brand new even though the code is old.