It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

How to Import Jira csv files without overwriting exiting issues Edited

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

1 answer

0 votes

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.

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

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.

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).

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"

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted in Jira

Demo Den Ep. 7: New Jira Cloud Reports

Learn how to use two new reports for next-gen projects in Jira Cloud:  Cumulative flow diagram and Sprint burndown chart. Ivan Teong, Product Manager, Jira Software, demos the Cumulative ...

334 views 1 3
Join discussion

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you