Unified Language User Guides
iCR User Guide 5.0
iCR User Guide 5.0
  • Table of contents
    • Introduction
    • Overview
    • Authorizing Access to Your Source Code
      • Authenticating GitHub Cloud Access Using OAuth
      • Authenticating GitHub Cloud Access Using PAT
      • Authenticating GitHub Enterprise Access Using OAuth
      • Authenticating GitHub Enterprise Access Using PAT
      • Authenticating GitLab Cloud Access Using OAuth
      • Authenticating GitLab Cloud Access Using PAT
      • Authenticating GitLab Enterprise Access Using OAuth
      • Authenticating GitLab Enterprise Access Using PAT
      • Authenticating Bitbucket Cloud Access using OAuth
    • Using the Navigator
      • Connecting to the Navigator
      • Setting your User Password
      • Updating your User Information
      • The Navigator top banner
      • The Analysis Engine status
      • Selecting Your Source Code
        • Using a cloud-based VCS
        • Selecting your branch
        • Using a private VCS
        • Using a local project
        • Limiting the files to be analyzed
      • Integrating with your bug tracking system
        • Integrating with Jira - Define Your Project
        • Integrating with Jira - Authorizing Access for iCR
        • Integrating with Jira - Connecting with iCR
    • Using the Analysis Engine
      • Initiating an analysis
      • Monitoring the analysis
      • Interrupting the analysis
    • Reviewing your results
      • Reviewer summary and filters
        • Filter by Severity
        • Filter by Category
        • Filter by CWE
        • Filter by OWASP
        • Filter by Directory
      • Reviewing a fix
      • Accepting a fix
        • Accepting a fix when integrated with your bug system
      • Rejecting a fix
        • Rejecting a fix when integrated with your bug system
      • Undoing a fix
        • Undoing a fix when integrated with your bug system
      • Rejected fix history
      • Providing feedback
      • Applying the fixes
      • Cases needing manual attention
      • Comparing Analyses
      • Capturing results for printing or sharing
      • Ending a reviewer session
    • When you are complete
    • Integrating iCR Into Your CI/CD Workflows
      • Jenkins Workflow
        • Installing the plugin
        • Configuring the plugin
          • Creating a Personal Access Token
          • Copying Your Repository's URL
        • Viewing the Results
      • GitHub Actions Workflow
        • GitHub Actions Overview
        • Preparing the GitHub Workflow
          • Environment Variables
          • User Supplied Secrets
          • Setting the User Defined Secrets Values
        • Executing the Workflow
      • GitLab CI/CD Workflow
        • GitLab CI/CD OverView
        • Configuring the GitLab Script variables
          • Environment Variables
          • User Supplied Variables
          • Creating a Personal Access Token
          • Setting the User Defined Variable Values
        • Executing the Workflow
      • Multiple Workflows
    • Appendix – Language Specific Fixer Lists
    • Appendix - Sample Bug Listing
    • Appendix - Getting a BitBucket App Password for JENKINS
Powered by GitBook
On this page
  1. Table of contents
  2. Reviewing your results

Rejected fix history

PreviousUndoing a fix when integrated with your bug systemNextProviding feedback

Last updated 3 months ago

Rejecting a bug indicates that, while an issue has been detected, the decision was made to not apply this fix. So, what happens to such bugs once a review of a session completes? iCR maintains a history of the rejected bugs so that they do not need to be processed in subsequent analyses.

Let’s use the example of the previously rejected bug OV-L-2. We will go back to the main Navigator page and click the Analyze icon button a second time. A new analysis is run. When it completes, we can click on the Review icon again and this time we see there are now 2 sessions.

We click on Show Results for Session 2 to bring us to the latest analysis where we observe that the Rejected tab already has a fix in it.

It is the one that was rejected from the first analysis. All rejected bugs from previous analyses are tracked and will always show in the Rejected tab. Clicking on it shows the rejected bug from the earlier analysis session.

Bugs that have been previously rejected have their severity icon greyed out. This tells you that this rejection comes from some earlier analysis. Previously rejected bugs are always displayed following any newly rejected bugs. In the example below, you can see that newly rejected bug CI-H-1 has the expected severity color while the previously rejected bug OV-L-2 is greyed out.

Rejected bugs are kept in the Rejected tab until they are eliminated from the code. Keeping them in the history allows you to change your mind in the future should you decide otherwise and choose to accept the bug later on. Also, the highest severity previously rejected bugs always follow the lowest severity newly rejected bugs. Rejected bugs are kept in the Rejected tab until they are eliminated from the code. Keeping them in the history allows you to change your mind in the future should you decide otherwise and choose to accept the bug later on. Also, the highest severity previously rejected bugs always follow the lowest severity newly rejected bugs.