-
Bug
-
Resolution: Not a bug
-
Medium
-
None
-
1
-
Severity 3 - Minor
-
Issue Summary
The External System Import feature automatically creates 1 custom field named External Issue ID per project to keep track of the original IDs of the imported issues. This is the actual system field Issue Id for which a field from the CSV file can be mapped during the CSV import process. This way, if an issue from a CSV file has the same External Issue ID as an issue that already exists in the project for which it is being imported, it should be skipped, so that duplicate issues are not created.
It turns out this validation for existing issues with the same External Issue ID within the same project is only being triggered during CSV imports to the project for which the custom field External Issue ID was automatically created by the External System Import feature for the first time.
Steps to Reproduce
Consider the following CSV files:
- first.csv:
Issue type Issue ID Parent Summary Task 1 Parent issue Sub-task 1 Child issue 1 Sub-task 1 Child issue 2 - second.csv:
Issue type Issue ID Parent Summary Task 1 Parent issue Sub-task 1 Child issue 3 Sub-task 1 Child issue 4
- Take a Jira Cloud instance on which no CSV imports were performed yet (or, at least, no CSV imports on which a field from the imported CSV file was mapped to the system field Issue Id). At this point, no custom fields named External System ID were automatically created by the External System Import feature.
- Import the CSV file first.csv into the project FOO. Map the field Issue ID from the CSV file to the system field Issue Id during this CSV import process. At this point, a custom field named External Issue ID is automatically created by the External System Import feature.
- Import the CSV file second.csv into the project FOO. Map the field Issue ID from the CSV file to the system field Issue Id during this CSV import process. Here, the first issue from the CSV file second.csv is not imported, as expected. This happens because that issue has the same value for the field Issue ID as an issue in the CSV file first.csv.
- Import the CSV file first.csv into the project BAR. Map the field Issue ID from the CSV file to the system field Issue Id during this CSV import process. At this point, another custom field named External Issue ID is automatically created by the External System Import feature.
- Import the CSV file second.csv into the project BAR. Map the field Issue ID from the CSV file to the system field Issue Id during this CSV import process. Here, all the issues from the CSV file bar-second.csv are imported, even though the first issue from the CSV file second.csv has the same value for the field Issue ID as an issue in the CSV file first.csv.
Expected Results
The validation for existing issues with the same External Issue ID within the same project should be triggered for all CSV imports, regardless of the project for which the issues are being imported. Taking the above example, the behavior observed for the CSV imports to the project FOO should be consistent for all projects.
Actual Results
The validation for existing issues with the same External Issue ID within the same project is not being triggered during CSV imports to projects for which the custom field External Issue ID was not the first one automatically created by the External System Import. Taking the above example, this is what happens for the CSV imports to the project BAR.
Workaround
Manually clean up the duplicate issues with the same External Issue ID created as a result of a CSV import.
- relates to
-
MIG-391 New "External issue ID" field is created on each import
-
- Closed
-
-
JRACLOUD-81999 Values mapped to "Issue ID" field upon import will be saved to "External Issue ID" custom field
- Gathering Interest