Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce the ability to migrate attachments #2

Open
brianoliver opened this issue Apr 5, 2017 · 3 comments
Open

Introduce the ability to migrate attachments #2

brianoliver opened this issue Apr 5, 2017 · 3 comments

Comments

@brianoliver
Copy link
Owner

Currently JIM doesn't support migrating attachments. One possible way to achieve this is to place the JIRA attachments in a special project folder/branch and then link to those.

@mskd12
Copy link
Contributor

mskd12 commented Apr 10, 2017

We were planning to leave the links as is and later update them after deciding the location of attachments. We would be dumping all attachments into some local machine for now. I am also planning to generate a mapping file which contains 3 columns - Issue ID, File Name, Attachment ID.
Using this mapping file and the attachments, we want to be able to later update the links in imported GH issues. Is there anything we can do now to make this process easier? (such as storing the comment id of attachment comment maybe?)

@brianoliver
Copy link
Owner Author

Perhaps we could create an index of them and/or download them all so that we can upload / fix links later? At least that way after a migration there's no dependencies on the old JIRA server?

@mskd12
Copy link
Contributor

mskd12 commented Apr 10, 2017

Yes, we would be downloading them all. And, hence we will not have any dependency on the old JIRA server.
Later, at some point, we should be replacing the text in comments to correct the links. So, we need a way to get to the comment containing the attachment link. One way to go about this is to search for a string such as "Attached By" which might uniquely identify this comment. As you can see, this method is not fool-proof i.e., some other comment might also have such a string. So, how should we go about this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants