CSV import, Next-gen, assign tasks to epics. Possible?

Heather Kendall

We are trying to import tasks into our next-gen product.

Notably, to gain access to any epic fields to map we cannot go through the project's csv import dialogs, but have to go to the system import dialogs.

When we look at "epic link" and similar fields in advanced view columns in our lists, the values are blank for tasks that are assigned.

So, we are wondering if there is something else we should be mapping (if so, what are the steps to make that happen?) or if the next gen projects just don't support assigning tasks to epics as part of the import yet.

Thanks!

Andy Heinzer

Hi Heather,

I see that you are looking to import issues into a next-gen project and are having some problems with maintaining the epic/child relationship.  Next-gen projects have a different means of determining an issue's epic than the classic projects do. 

In classic projects, issues will tend to have an epic link field that references the issuekey of the epic itself, this epic link field is a global field, meaning it is used throughout all projects in Jira.  However next-gen projects don't actually have this global epic link field to use.  Instead they are showing this relationship by referring to the epic's issueid under the parent field.

If you are exporting this from another next-gen project, then when you do so you can see something like this:

Every issue will have a unique issue id.  That issue id of the epic type issues is referenced in the parent field.  That same parent field is also used to link subtasks to their parent task issues. So it is possible to maintain this epic link in a next-gen, but you have to do things a bit differently here.  First, we need to make sure that the issue id you are importing here are unique to this Jira site.  If they already exist in Jira, then using the external system importer could overwrite existing data.  In this example above, GOG-9 is one of the epics (which an issue id of 10233), and its child issue is GOG-1 which references that id in the Parent field.

I think the best way to manage this is to actually break it up into two imports: first import of just the epics themselves and the second import will then bring in all the other issues. 

When you do this first import, don't map the issue id or issuekey fields.  That way these imported issues will be considered new issues will have their own new unique issue id values.  Mapping the issuekey or issue id could overwrite/update existing issues that would match on those values.

After you import the epics, you can then do a new export of just the epics to see what their issue id values are, and then use that information to update the csv for the second import so that the parent field will match that issue id value of the epic.  Provided that the second import maps that parent field and the new csv file as this updated parent id value, this should work.  Admittedly this is more complex to achieve, but I believe it is possible.  If this project has subtasks, you might have to break this up into three imports to accommodate the subtasks relationships in the same manner.

Let me know if you have any questions or concerns about this.

Andy