DevOps > Jira Attachments

Originally asked by nick watts on 25 September 2020 (original question)


Hi

Jira > DevOps integration = Images attached to comments sync across and appear in the links tab.

DevOps > Jira integration = images do not sync across when syncing, either from comments of attached in the description.

Has anyone encountered this?

Thanks


Answer by Francis Martens (Exalate) on 26 September 2020

This is indeed the case and on our roadmap to improve on
It is a bit of a pain as Azure DevOps doesn’t provide REST access to inline attachments …

There is a similar problem syncing zendesk inline attachments. Check following post
How to transfer inline attachments from zendesk to jira (old community)


Hi everyone, just checking in to see if there are any updates.
It’s been a little while, and I wanted to follow up.

Thanks in advance!

Hi @Angel_Hidalgo ,

I have run testing with the following, and it has worked for me and my colleague locally here. Could you please check this out and let me know the result?

//ADO Outgoing sync script:
replica.description    = workItem.description
replica.comments       = workItem.comments

//ADO Incoming sync script:
workItem.description  = replica.description
workItem.comments     = commentHelper.mergeComments(workItem, replica)

//JC outgoing sync script:
replica.description = nodeHelper.getHtmlField(issue, "description")
replica.comments = nodeHelper.getHtmlComments(issue)

//JC incoming sync script:  
issue.description  = nodeHelper.toMarkDownFromHtml(replica.description)
issue.comments     = nodeHelper.toMarkDownComments(commentHelper.mergeComments(issue, replica))

Kind regards,
Ashar
Exalate

1 Like

Hi Ashar.

The problem are the attachments.
The filename of the file sync from ADO to JC is always the same: image.png

I add here my attachment config:

// ADO Outgoing sync script:
replica.attachments    = workItem.attachments

// ADO Incoming sync script:
workItem.attachments  = attachmentHelper.mergeAttachments(workItem, replica)

// JC Outgoing sync script:
 replica.attachments    = issue.attachments

// JC Incoming sync script:
issue.attachments  = attachmentHelper.mergeAttachments(issue, replica)

Thanks !!

Hi @Angel_Hidalgo , I have tested with these rules. Result was, file name .jpg remained intact. I attached within Azure Work Item from ā€˜Attachment’ button on right side. I have also tested with an inline image along with a comment. Please give it a try, and let me know.

ADO - Outgoing:
replica.attachments = workItem.attachments
ADO - Incoming:
issue.attachments = attachmentHelper.mergeAttachments(issue, replica)

Jcloud - Outgoing:
replica.attachments = issue.attachments
Jcloud - Incoming:
issue.attachments = attachmentHelper.mergeAttachments(issue, replica)

Screenshots: Unique Download Link | WeTransfer

Hi,

Thank you for your response and for testing the attachment scenarios.

However, the issue I’m experiencing is not related to files attached through the ā€œAttachmentā€ section of the Azure DevOps work item. The problem occurs specifically with images inserted directly into the comments of a DevOps work item (for example, pasted inline or uploaded via the comment editor).

These inline images appear correctly in Azure DevOps, but they do not get transferred properly through the synchronization process. Either they are missing in the destination system or appear broken.

Could you please confirm whether inline comment images are supported in the current integration setup? If not, is there any recommended workaround or planned support for this?

Thanks again for your help.

Best regards,
Ɓngel Hidalgo

Hi @Angel_Hidalgo / @ashar.iqbal ,

This should fully work bi-directionally between Jira Cloud and Azure DevOps since Exalate 5.12.0. The key is to use the correct nodeHelper methods to do the transformations.

The scripts you basically need are the following:

JC Outgoing:

replica.description = nodeHelper.getHtmlField(issue, "description")
replica.comments = nodeHelper.getHtmlComments(issue)

JC Incoming:

issue.description  = nodeHelper.toMarkDownFromHtml(replica.description)
issue.comments     = nodeHelper.toMarkDownComments(commentHelper.mergeComments(issue, replica))

ADO Outgoing:

replica.description    = workItem.description
replica.comments       = workItem.comments

ADO Incoming:

workItem.attachments  = attachmentHelper.mergeAttachments(workItem, replica)
workItem.comments     = commentHelper.mergeComments(workItem, replica)

Here is a video of my latest test:

Hope it helps.

Thanks
Majid

Hi Majid.

Thank you very much for the video — it really helps to understand the process better. I’m sharing a screenshot so you can see that the images posted in comments from DevOps are all named image.png . If there’s only one image in the comment, it works fine. But try adding more comments from DevOps with additional images (either in the same comment or in separate ones), and you’ll notice that all of them are named image.png . If I get the chance, I’ll also try to upload a video to show you.

Interesting problem - let me repro. So the actual inline images etc. work for you still? Or do they even not work due to the name thing?

A couple of attachments.


Got it!
So it works, but the filename is the issue. Thank you for clarifying!

Hi @Angel_Hidalgo,

I was finally able to sync inline images. Interestingly, unlike you and Majid, I’m seeing the images synced with the correct filenames—using the exact same script you’re both using. As shown in the screenshots below:


@Majid, if you try uploading two images in the same comment, do you encounter the same issue Angel described?

In the meantime, I’ll keep digging into it.

@Javier I was unable to test the image name thing - never got the time. I will try today and let you know, but if you are unable to repro, this might not be a bug.

Hi.

I tried to record a video with the problem:

Hi @Angel_Hidalgo,

I believe I’ve identified the root cause. I was able to reproduce the behavior you described, and I found that when using tools like the Snipping Tool or Screenshot Tool, the system assigns the default filename ā€œimage.pngā€ to each image. When two such images are added to a comment in Azure DevOps (ADO), the integration sends both with the same filename.

As a result, Jira Cloud displays the same image twice, even though two different images were originally added. This appears to be due to Jira interpreting both attachments as the same file because of the identical names.

However, if you save or rename the images with unique filenames before inserting them into the ADO comment, Jira Cloud correctly displays both images.

Recommended Workaround:
Try saving your screenshots with different names (e.g., image1.png, image2.png) before pasting them to the ADO comment. This should resolve the duplication issue you’re seeing in Jira Cloud.

Please let me know if this solves your issue

Thanks to @Javier for letting me know that this thread was going on.

We have the same issue whereby if an image is copied (rather than saved and attached), when the images sync across from Azure DevOps to Jira, Exalate will add the comment with the same image name.

However, if you look at the screenshots shared by @Angel_Hidalgo, the images have different IDs within the Exalate replica.

Could Exalate use these IDs instead of the filenames to identify which image should be shown?

This would help as we are currently pasting screenshots etc as single comments to work around this issue - which is not ideal.

@MikeFowler,

We reviewed this with the team and confirmed that the issue stems from a Jira Cloud limitation, not Exalate. Jira Cloud uses the filename as an identifier for images. When images with the same name are added in a comment directly within Jira Cloud, the system automatically appends a differentiator (such as a date and timestamp) to the filename. However, when images are added via the API, this behavior does not occur.

With that in mind, we’re exploring a workaround by implementing a Groovy script in the Outgoing sync of Azure DevOps. Our goal is to handle the image duplication issue without requiring images to be manually saved with a different name before being copied into the comments.

I’ll keep you updated on whether this solution works as intended.