How to Import Jira csv files without overwriting exiting issues Edited

[Nic Cusack]

Background:

Two data bases physically separated each with two Projects.

One Project is used to collect all the bugs raised in the other Projects.

The mechanism used is that the Projects export their bugs to csv.

The one Project imports the bugs using those csv files.

Problem:

The key used in the different Projects sometimes overlaps so when importing the bugs overwrite each other where the key matches.

Question:

How do I overcome this so I can import the bugs and update those bugs imported from other Projects without overwriting

[Nic Brough {Adaptavist}]

If the CSV contains an issue key, then Jira will look for a matching issue key and assume the data being imported is an update to that issue.  If it can't find one, then it has to assume it's a new issue.

For any issue being exported, you need to decide if it is an update in the target system or a new issue, and remove the issue key from the CSV if it is supposed to be a new issue.

[Nic Cusack]

I can see that working for for the initial import but how do I import updates to that issue in subsequent imports?

[Nic Brough {Adaptavist}]

You need to get the new issue id after the import, and use it in the next import file, so that the target system knows it is an update.

CSV is actually a really poor way to do this, it's more suited to one-off migrations and bulk updates.  What you're doing is more of a synchronisation.  I would recommend looking at the apps in the marketplace that can do regular (and more frequent and totally automatic) syncs between two Jira systems. 

I'm most familiar with Backbone and Exalate for example, but there are a couple of others which might suit you as well.

[Nic Cusack]

HI,

I will have a look at these tools but the issue I have is that to be able to transfer the data has to be reviewed prior to release by a third party and they do not have or want access to JIRA (yes, I know that is a pain).

[Nic Brough {Adaptavist}]

I think you already know that I would suggest a workflow that does "approval in Jira before sending to other system".

But, if they don't want access, that's understandable.  I think the sync tools might still be able to help you with automating a lot of it outside the reviews you have to do, but I am stuck on the human review process.

The "evil engineer" in me wants to tell them "Reviews in Jira are a read (optionally edit) and click to accept or reject.  Manual reviews require you to read and edit a spreadsheet, get it validated (with no indication of what the error is if you make a mistake), post it to IT, who are under no obligation to process it for weeks if they have more important stuff to do".

I know that is very passively aggressive.  Making life harder for people who refuse to accept to do things better is a last resort though.  I'd prefer to try to get them to look at a new process and say "I'd like to do it that way please"