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.
The key used in the different Projects sometimes overlaps so when importing the bugs overwrite each other where the key matches.
How do I overcome this so I can import the bugs and update those bugs imported from other Projects without overwriting
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.
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.
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"
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 ...
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