Issue linking via CSV using a single Dependency column

[YARON LEVY]

HI, 

I'm doing a data migration, and the method I've chosen is:

1. import all issues (after a large scale data manipulation)
2. import all links.

About the links- I have 2 options: 

1. get a comma delimited linked issues - This option meens I have to link to do an Excel work - separating the field into column, and giving every column a "Dependency" name.
   for ex.: 
   issue key, Dependency,          Dependency          , Dependency
   issue A , Dependency Link A, Dependency Link B, Dependency Link C
2. getting multiple rows, with same issue, every row linked to another issue.
   for ex.: 
   issue key, Dependency
   issue A , Dependency Link A
   issue A , Dependency Link B
   issue A , Dependency Link C
   
   

I like option number 2. I prefer not doing Excel manipulations, when i have the option not to.

I saw it is actually working and only adding more links. (Unlike Labels which replaces the labels with other ones).

I just want an approval from JIRA official it is acceptable, since I didn't find any documented working method like this.

Thanks,

Yaron

[Leo Acosta]

Were you able to make this work?  It fails for me.  What I am experiencing is that the import tool actually creates completely new issues with the dependencies specified in the CSV rather than linking properly to the existing issues in Jira.

[Dave Theodore [Coyote Creek Consulting]]

You aren't going to break anything. You may end up with data that doesn't represent what you actually want, but there is no other harm in what you propose.

You will need to include one additional column in your CSV, though. You need the issue Summary. Like the label behavior you describe, the CSV importer will replace the current value with what is in the CSV, so you should build your file with the correctly associated Summary for each IssueKey.

[YARON LEVY]

Thanks Dave !

So, to clearly summarize: 

I can add more and more and more links to issues using my method (instead of creating multiple link columns) - Just to be careful to use the correctly associated summary.

for ex.

importing This: 

issue key, Summary, Dependency
issue A,  blabla, Dependency Link A
issue A,  blabla, Dependency Link B
issue A , blabla, Dependency Link C

Will get me the same results as importing this:

issue key, Summary, Dependency, Dependency, Dependency
issue A,  blabla, Dependency Link A, Dependency Link B, Dependency Link C

And, This works only for links. not Lables.

With lables I must use multiple columns.

B.r,

Yaron Levy

[Dave Theodore [Coyote Creek Consulting]]

Any multi-value field needs to have each value in its own column. This also applies to comments and attachments, as they behave the same way as a multi-select list field.

In essence, you are doing the same thing in both of your examples, however, the top one, you are doing multiple imports to the same issue vs a single import per issue.  I would expect the top method will take longer to import.

[YARON LEVY]

Yes, Probably will take longer, but since there are not so many links, its not so bad, and also It saves me Excel-Macro / Manual tedious job.
The source system admin runs some Join queries on his DB and gives me Many to Many linked issues list.

BTW, could you refer me to some useful Excel or other text manipulation tools that can help me with migrations ?

B.r,

Yaron Levy

[Dave Theodore [Coyote Creek Consulting]]

We usually do text manipulation using scripts. The exact method varies by engineer, as I have varying experience on my team. If you're fairly adept with sed and awk, you can do this sort of thing easily in bash, using those two utilities. Otherwise, python and perl are good for this sort of thing.

When we are forced to use a spreadsheet editor, we do not use Excel.  For some reason, Microsoft imposes limitations that are not part of the CSV standard.  There are maximum cell size limits and it seems to struggle with nested commas and double quote marks.  I would recommend using Openoffice, as it handles CSV a lot better.