- Sonar Version: 22.214.171.124397
When I’m trying to find issues in a particular file I open up the FILE section and select a given file:
main.c and I can see the url directs to
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:
src/submain.c and I see the url directs to
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
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.
I’m not sure what you mean by “not meant to work this way”. I’m not manually navigating to the uuids, I’m pointing out that they’re not working.
I’m clicking on a file filter :
src/submain.c and seeing that the url doesn’t look correct and isn’t working.
Could you share some screenshots of what you’re clicking on and what you’re getting in response?
api/documenttypes.c redirected the url to:
Clicking on a file not in a subdirectory changes the url to:
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.
So you’re saying that there really are 0 issues in the file
So if i get to the issues in that file from other means besides the filter by file option I should also see 0 issues and not 38 code smells?
That’s what your screenshot indicates.
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
- 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
Thanks for taking the time to report this. This is indeed a bug, and I opened a ticket here. We will try and fix it for the next release (8.5).
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.