Jira JSON import - attachments

[Lorenz Lauwaert]

Hello,

I'm trying to import our tickets from a YouTrack instance to a Jira intance.

I created a JSON generator that successfully generates the JSON import file, except for 1 problem, importing the attachments gives an error.

This is a sample of the attachment part of the JSON file:

"attachments": [
{
"name": "3ADEF-2358.PNG",
"uri": "https://xxxxxxxxxxx/api/downloads/3ADEF-2358/3ADEF-2358.PNG",
"created": "2018-03-08T14:07:52.248Z",
"description": "Added via YouTrack import",
"attacher": "email@email.com"
}
]

The json is valid and the import succeeds in everything except for the attachements.

For every attachment in the file I get this reported:

• An exception occurred dealing with attachment 'https://xxxxxxxxxxxxx:3200/api/downloads/3ADEF-2358/3ADEF-2358.PNG'.

If I check the detailed log this (similar) line is showing

2018-03-08 14:09:13,445 WARN - An exception occurred dealing with attachment 'https://xxxxxxxxxxxxxx:3200/api/downloads/3ADEF-2358/3ADEF-2358.PNG'.

There is nothing else to indicate what the exception is. Maybe with a stack trace or exception message I would have a clue on what's wrong.

The file is perfectly downloadable when I copy paste the URL in a browser. The attachments are all kinds of files also.

Is this a HTTPS issue? Can I somehow find out what exactly is going wrong?

If anyone could give me assistance I would be very happy.

Thanks!

[Kyle Moseley]

Could it be working for you through your browser because you're authenticated (while JIRA may not be)? Also, if this import is happening on JIRA, can JIRA's machine ping that URL from the command line?

[Lorenz Lauwaert]

Hi and thanks for the answser.

Unfortunately that isn't the issue. Initially I had linked the attachments straight from youtrack and that indeed had such an issue.

I wrote a scraper that downloads all attachments and hosts them online, the importer uses the online links for the images.

I can navigate to them by copy pasting the link in the error log from any location (even tested with smartphone over 4G).

The only thing I can think of right now is that the URL contains a specific port (e.g. https://myhost:3200/api/getfile/attachment.txt)

If that could be related I can always try to copy the attachments under the IIS portion of my web server so there is no port needed?

Thanks for the answer though.

[Lorenz Lauwaert]

It seems my last hunch was correct.

I adjusted one of the links to be hosted under the IIS with default port 80, this is the only attachment that was properly added when importing.

It seems that the importer has a few limitations, it might be interesting that these are documented on the JSON importer page.

- attachment links cannot be behind any authentication (obviously, but people will run into this)

- attachment links cannot use any other port that the default one in their link (or better yet, no mention of a port), (https://host:port/file.txt does not work, https://host/file.txt does work).

[edit] Another improvement would be to show proper error details, at least in the detailed log. The log seemed very interesting, yet it did nothing to help me during the import effort other than just saying something failed.