Handling of Edited Inventory During Rescans

Code Insight enables you to make changes to inventory both in the Analysis Workbench and on the Project Inventory tab. You create inventory items as well as edit both user-created and system-generated inventory. Edits to existing inventory can include changes to the following elements in an inventory item:

• The component version string or the associated license
• Codebase-file associations (only in the Analysis Workbench)
• Inventory properties, Notices text, and notes

However, normal Code Insight rescan behavior can result in actions that impact your inventory changes. For example, an updated Automated Analysis rule set might associate codebase files to an inventory item different from the one to which you have manually associated these files. Logically, the rescan should remove the associations you defined and re-apply them to the inventory item identified in the rule set. However, losing the manual changes might not be desirable.

The following topics describe how the rescan process handles edited inventory:

• Rescan Rules to Preserve Inventory Data
• Rescan Scenario: Handling of Files Manually Disassociated from Inventory Before Rescan

Rescan Rules to Preserve Inventory Data

In general, a rescan (full or on only changed files) can add or disassociate files and overwrite properties for any existing system-generated inventory that has not been manually updated. However, the rescan does retain the existing status and priority for such inventory items, as well as any existing notes or Notices text (although the scan can append new notes or Notices text).

For inventory that you have manually edited or created, the rescan applies the following rules:

• All the user-created inventory, its file associations, and edits are considered not system-updatable and therefore are preserved.
• Any manual change to a system-generated inventory item (including updates to the associated component) results in the inventory item being classified as user-created and therefore not system-updatable (see the previous rule.) However, the rescan can add additional files to the inventory item if the component, version, and license match.
• If one or more files were manually disassociated from a system-generated inventory item before the rescan, rescan logic assumes that these files were erroneously associated with the component initially. Therefore, the rescan does not attempt to re-associate these files to the inventory item; nor does it associate the files with another inventory item that uses the same component name (with a different version or license). The following example scenario illustrates this rule.

Rescan Scenario: Handling of Files Manually Disassociated from Inventory Before Rescan

The following scenario demonstrates how the rescan process handles files that you manually disassociated from a system-generated inventory item before the rescan.

Scenario

In this scenario, the initial scan on your codebase generated the inventory item log4j 2.6 and associated the files file1.jar and file2.jar with the item.

However, after analyzing the inventory, you realize that file2.jar should be associated instead with log4j 2.11, an inventory item that does not exist in your current inventory. To remedy this, you perform the following steps:

1. Create an inventory item named log4j 2.11.
2. Disassociate the file2.jar from log4j 2.6.
3. Associate file2.jar with the inventory item log4j 2.11 that you just you created.

On rescan, your edits remain intact:

• The file file1.jar remains associated with the inventory item log4j 2.6.
• The inventory item log4j 2.11 that you created is preserved along with its association with the file file2.jar.

The rescan also results in the creation of a new system-generated inventory item, log4j 2.10. However, the rescan does not associate the file file2.jar with the new inventory item.