Rejected fix history

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 for Python 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 SDE-PyRRG-1-2. We will go back to the main Navigator page and click the Analyze button a second time. A new analysis is run. When it completes, we can click on the Review button again and this time we see there are now 2 sessions.

We click on Show Details 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 SDE-PyRRG-1-2 has the expected severity color while the previously rejected bug In-PyFT-18-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.