SonarQube only shows issues in pull requests that have locations involving lines of code that were changed in that P/R.
This strategy filters out a lot of issues that are not relevant to the P/Rs, and brings the focus to the code that was changed in the P/R.
However, it's possible to have issues that were already present before those changes. In other words, there is no guaranteed causality between a change in a line and an issue located in that line, resulting in false positives in pull requests.
If an issue already existed the target branch of the pull request, and it was resolved (for example, marked as "won't fix"), we should hide it in the P/R.
We do "issue tracking" with the pull request itself, to keep changes done by the user to issues in the pull requests. We should also do "issue tracking" with the target branch (if it exists in SonarQube).
This issue tracking should be done in all analysis of the PR (not only when it's first analyzed) so that we hide the issue in the P/R if the status changes in the branch at any time, even after the creation of the P/R.
This way, the P/R will show issues that will actually show up in the target branch after the merge of the P/R to the target branch.