CSV Importer: Parent work item unlinking

Question

Context: We are in the middle of moving from Jira team-managed space custom fields and creating their global field counter part. With that, we need to migrate the data that lived in the space custom fields to their global field counterpart.

Goal: The only way I can think of to mass update the existing work items in each space is through the CSV importer (old version).

Problem: When I update the the child work items (not sub-tasks), the relationship between its parent (Epic) and the child work item is disconnected. So I am left with orphan work items that have the data updated in the global field counterpart.

Attempts:

* Included an Epic parent column in the CSV file and mapped it out to "Parent" * Importer gave be an error to include the issue ID and tried the parent key

* I have not been able to move past this step when I include a parent mapping

* I have been able to move past this step without including the parent column but the trade off is all the orphaned child work items are the result. So we have been manually linking them for the few hundred we test this on.

Trudy P Claspill · Answer

Adding to this,

There are currently unresolved bugs with using the CSV importer (old experience) to connect child issues to an Epic, both when the Epic already exists in Jira and when the CSV file includes the data to create the Epic. I expect that the root cause behind the errors you get when trying to include the Parent field as part of the CSV mapping.

https://jira.atlassian.com/browse/JRACLOUD-92272

https://jira.atlassian.com/browse/JRACLOUD-96848

I had not tested the scenario of trying to update other fields in an existing child issue. Thank you for sharing the information that this causes the link to the parent Epic to be broken.

I strongly recommend that you ask your Jira Administrators to open a support case directly with Atlassian to report that specific problem, in case they are not already aware of it.

In addition to @John Funk 's suggestion to use Automation, if you have folks comfortable with coding you could investigate creating custom code to retrieve the issues and copy data between the fields. You said you have to do this for over 100k items. Using a Scheduled Automation Rule for that will result in the rule hitting service limits for Automation, and it could take many days to get through updating the issues.

I had a similar experience where I was hitting automation service limits ; the limit on the number of issues a single run of a Scheduled rule could process, and then the limit on how much cumulative run time a single rule could have in a 24 hour time period. I ended up manually triggering the rule until hitting the cumulative run-time limit, then copying the rule, then starting to manually trigger that second copy, then making a third copy, and so on. And then having a copy of the rule that I would let run a couple times overnight.

For a code solution you could either generate custom code to interface directly to the REST API, or if you have an app like ScriptRunner you can use that to create your custom code.

John Funk · Answer

You can probably to an automation rule to just update the fields then.

Create an automation rule with a scheduled trigger. Use whatever time period you like because it really won't be relying on that.

The add a JQL to the scheduled trigger to get the issues you want. Yes, you might have to limit the number you are doing but it will be cleaner.

Then add an action for Edit work item. Select the new custom field and then copy it from the same issue/work item and then select the existing custom field.

Update all of that to save it.

Then click the 3 dots in the upper right and say Run rule.

Mireya Cintora · Answer

So we aren't moving the items to different spaces it would be within the same space. Reason is because some of these projects have over 100k items and we can only move up to 1000 items at a time.