When I’m trying to find issues in a particular file I open up the FILE section and select a given file:
Select main.c and I can see the url directs to ?fileUuids=AXizT514........&id=project&results=false
It seems that some files don’t have a valid uuid built. I’m not 100% positive, but it looks like any file that’s not in the root of the project don’t filter properly:
Select src/submain.c and I see the url directs to ?f=fileUuids=project%3Asrc%2Fsubmain.c&id=project&results=false
Page shows “We couldn’t find any results matching selected criteria”. But I know there are issues, because I can get to issues in this page from the global issues list without filtering.
When I click the link from the global issues list, the fileUuid does look to be generated properly, so I’m guessing that this is a js issue when the file contains / characters.
It’s not meant to work this way; the uuids are not for public consumption. However, you should be able to navigate to everything via normal use of the interface.
Clicking on api/documenttypes.c redirected the url to: https://...../project/issues?fileUuids=myProject%3Aapi%2Fdocumenttypes.c&id=myProject&resolved=false
Your first screenshot shows the selection of a file without any open issues. That’s why the right pane is blank. How do I know that? Because of the 0’s that show up in the open Type and Severity filters at the top of the page. This has nothing to do with where the file is located in the project.
Another way to approach this is from the Code view. E.G.
Compare the file selection in the two different screenshots and you’ll find they’re different: “webchart:/api/docu…” versus “api/documenttypes.c”.
I can’t tell you more without understanding your project structure. I get the feeling you think I’m trying to pull the wool over your eyes. I’m simply reading the screenshots you provided.
This is why I’m trying to report the bug. I have no control over how sonar decides to display its file filter values. The fact that it shows 1 as a simple file path and another prefixed with the project and a colon is out of my hands.
Unless I’m massively misunderstanding sonar’s UI, I’m trying to report that sonar is saying 0 issues are in this file, while obviously from the last screenshot you can see that there are 38 code smells. I’ve provided the formatting of the relevant urls as a starting point which I think is related.
Compare these two workflows using the exact same project for each:
Showing No Issues
Click on a project (WebChart)
Click the issues “tab”
Open the “File” filter
Enter “documenttypes”
Select “api/documenttypes.c”
** We couldn’t find any results matching the selected criteria
** No other filters were applied
Showing Issues
Click on a project (WebChart)
Click the code “tab”
Enter “documenttypes” into the “search for files” filter
Select “documenttypes.c”
Verify sonar recognizes that the full path of this filename is: “api/documenttypes.c”
Click the “Code Smell” link that says 38
View resulting screenshot showing a list of 38 code smell issues on the right.
I don’t know why the filter values look different in the screenshots, but I’ve just given you the two workflows to arrive at each screenshot.
I can assure you this project only has a single file named “documenttypes.c” and it is located in the “api” subdirectory.
This issue discrepancy exists for every single source file contained in my “api” directory. The discrepancy also exists in a number of other directories as well, but for some reason not all of them.
Filtering by a file in a subdirectory named “webchartdb” -> url changes to issues?fileUuids=[VALIDUUIDFORMAT]&id=webchart&resolved=false and it shows issues
Filtering by a file in a subdirectory named “api” -> url changes to issues?fileUuids=webchart%3Aapi%2Fdocumenttypes.c&id=webchart&resolved=false and it incorrectly does NOT show any issues
Filtering by a file in a subdirectory named “messenger” -> url changes to issues?fileUuids=webchart%3Amessenger%2Fmessenger.c&id=webchart&resolved=false and it incorrectly does NOT show any issues
