Reviewer summary and filters
Last updated
Last updated
The Reviewer results are displayed across 2 panes. At the left is the Filters pane. The filters provide a number of ways of both restricting what is available for review and to focus upon certain aspects of the results.
The width of the Filters pane is ajustable by hovering over the divider line. Once the horizontal scroll cursor appears, you may widen or shrink the width of the Filters pane as you prefer. Also, the Filters pane is scrollable such that if many of the filters are in use, you may scroll up and down to review your filter selections.
There are 5 filters available. Each of these is covered in their individually linked sections:
The filters work as the intersection of all selected filters. That is, from the chosen filters in each of the filter classes, if something other than Select All is clicked, then only items specifically chosen are displayed. An obvious example demonstrating this, is that if, under the Severity filter, none of High, Medium or Low are clicked and Select All is also not clicked, then zero bugs will be displayed even if other filter categories are selected.
NOTE: If there are no issues in one of the categories of CWE or OWASP, then this filter will not be displayed.
The right side of the window is the Results pane. This is where the rolled up summary results are displayed followed by the detailed results. The top section displays a quick summary of the results. The Session number and the total number of fixes produced by the analysis approved shown along with information about which fixes have been selected for display. At launch, all fixes are displayed by default.
The branch name that was the subject of this analysis is also displayed. More importantly, there is an additional branch name displayed. When you accept and then apply fixes, the Reviewer will create Git commits and apply them to a new, temporary branch in your repository. This allows iCR to automatically update your source code in a fashion that allows you to prepare and review pull-requests before merging them into your actual project branch. In this example, the temporary branch is named: iCR-master-20250114043648.
The tabs summarize the states of the various fixes.
When the Reviewer is first launched following a fresh analysis, all the fixes generated are accounted for in the Unresolved tab. It shows the total number of fixes (130 in this example). The other states of a fix are:
Accepted – This fix has been approved for future application to the code base
Rejected – This fix has been rejected
Manual – There were conflicts in accepting all of the fixes so some manual intervention will be required
Fixed – These are fixes that have been accepted and applied to the code base. Their state can no longer be changed
Note that each of the above tabs will show the total number of fixes in that state. If there are no fixes in that state, the tab will be inactive. How the state of a fix is modified will be described in other sections.
Up to 10 fixes are presented at any one time. The bottom of the Fixes pane shows the number of pages of fixes available for review and allows navigation across the pages.
Each fix is identified with a unique Fix ID to help to distinguish each fix as it moves through the system. In the example below, the fix ID is CI-H-1. There is a title for the fix: Always Synchronize on a private final Field, and the category within which this fix belongs: Concurrency Issues.
There is also a description of the fix which includes the file name where the fix was produced: GossipSubjectImpl.java and optionally, depending upon the specific language being analyzed, the relevant method or class. In this example the method: registerObserver is called out. This information makes it easier for you to find the specific place in the code where the fix is being applied.
Also notice that some of the text is highlighted with hyperlinks. The links help you to understand the problem in more detail and to understand the suggested fix. In this example, clicking on the link CWE-412 will take you to more information on the Common Weakness Enumeration (CWE) that is identified in this fix.
In the top right corner of the description is an icon that presents OpenRefactory’s view of the severity associated with the bug being displayed. There are three levels of risk being assessed:
Higher severity bugs represent flaws that represent greater potential vulnerabilities if not corrected. The results are presented in the order of higher severities first. Of course, you may choose to use the Severity filter to affect what levels of severity you wish to see.
