Uploaded image for project: 'Minimal Marketable Features'
  1. Minimal Marketable Features
  2. MMF-441

Don't show resolved issues in connected mode in SLI


    • Type: MMF
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Labels:



      Currently, SonarLint for Eclipse and IntelliJ show every issue that the language analyzers find, according to the quality profiles in use. While using the connected mode, even though the settings and QPs match the ones used by the project in the SonarQube server to which SonarLint is bound, SonarLint won't fetch the current issues and their statuses.
      As a consequence, SonarLint will still show issues that are marked as resolved in the SonarQube server (false-positive, won't fix, fixed) and it is impossible to "silent" an issue in SonarLint.

      Use case

      As a developer, I review issues that I introduced yesterday on the master branch and that ended up in SonarQube. An issue of file A is a false-positive, so I mark it as such in SonarQube. Then I start a new development in my IDE, and at some point of time I open file A to write some code: I expect SonarLint to not show the false-positive issue in the editor nor in the "SonarLint Issues" view.
      Same should apply if I open another file on which a team mate has flagged an issue as false-positive or won't fix.

      Ideally, I shouldn't have to do anything nor wonder about to benefit from this feature.


      When using the connected mode, match issues found locally in SonarLint with the ones in SonarQube and use that information to hide issues that are marked as resolved in SonarQube.

      Technical spec

      Fetching issues from SonarQube

      This will be done at least at the following moments:

      • During the update of a binding, use the internal WS batch/issues to fetch all information regarding all issues in a project and store them in the local storage.
        • The storage should be organized per file.
        • SonarLint will then work completely offline, as it is currently the case.
      • When opening a file, fetch the issues for that file in order to be sure that the latest available information is used
        • If we feel that it's not enough, it will still be possible later on to add a kind of timer to fetch issues more frequently on opened files

      Issue tracking

      • Every time an analysis is completed, perform issue tracking and save the current issues.
      • Initially, track issues in files being edited against the ones fetched from the server. In the following analysis, compare the issues against the last local set of issues. This incremental matching of issues should be more precise than always comparing against the initial set of issues fetched from SonarQube.
      • If possible, detect renaming of files (at least when it's done within the IDE) and save the link between the new name and the old name. The link should be used during issue tracking to find the file with which the matching should be done.

      Using the information from remote issues

      • If an issue is not matched with an issue from SonarQube, the creation date (which appears in the "SonarLint Issues" view) should be the date when the issue was first created locally. This is what is currently done as the local leak period.
      • If an issue is matched with an issue from SonarQube, the creation date should be the one fetched from the remote issue, i.e., it should be the date when the issue was first created in SonarQube. Matched issues that are resolved should be completely hidden.


          Issue Links



              • Assignee:
                christophe.levis Christophe Levis
                duarte.meneses Duarte Meneses
              • Votes:
                5 Vote for this issue
                8 Start watching this issue


                • Created: