rory and bmurphy3, thanks for letting us know the issues you've experienced.

rory, I searched in our support tickets and it seems like your issue has been resolved by our support team. Let us know if you see this coming up again.

bmurphy3, I'd suggest that you open a support ticket: https://support.atlassian.com/customer/servicedesk-portal?utm_source=landingpage. Your customers should be able to see attachments and if they can't right now, either there's a bug or there might be a configuration issue with the comment field's renderer (it needs to be the wiki render). Either way, our support team can help you the best.

My customers cannot see attachments either. I end up having to email them images/files, which completely defeats the purpose of the Service Desk! Please FIX. This has been an issue since we starting using this product 2 years ago.

Hi everyone,

I'm excited to report that we've shipped the improved way for service team members to add customer-visible attachments to both Cloud and Server – they can now drag and drop them to an issue or the comment box.

Here's some information about it:

• Documentation on how attachments work: https://confluence.atlassian.com/servicedeskcloud/attaching-files-and-screenshots-to-issues-780868218.html
• Release notes for JIRA Service Desk 3.0: https://confluence.atlassian.com/servicedesk/jira-service-desk-3-0-0-release-notes-770801761.html

And here's a screenshot:

Thanks for choosing JIRA Service Desk!

The team

Atlassian should definitly fix this.

As a workaround, you can easily code this in a Listener plugin. You just have to add the wiki comment programmatically whenever an image is added to an issue.
You have to determine if files has been attached, then add the wiki comment using the filename. Do this for every new attachements on creation and update events.

We have just discovered this issue. I need a fix for this ASAP. The workaround using attachment markup in https://jira.atlassian.com/browse/JSD-43 is not a suitable solution. Please add this to the pipeline ASAP.

Should be essential in Service desk.
Shame that is doesnot work now.

It's not proper that a new release of SW will change completely the beheaviur of the SW itself and Customer have to wait so long to have a solution!!
for JIRA !!

I hope this will fixed in the near future. It's really annoying to explain why somebody can't see attachments in the customer portal.

The best should be an attachment section within the customer view.

Their was some insight by Edwin in JSD-43

info204, you are correct. I pinged the relevant parties to review it and see what we can do about this stalemate.

Email doesn't currently work though. See JSD-1361.

pierre.chabanian, if you open the comment area on any JIRA instance, in the bottom left hand corner is a little ? icon. If you click that icon, it will show you the help and examples for wiki markup. On this instance, it can be seen at: https://jira.atlassian.com/secure/WikiRendererHelpAction.jspa?section=texteffects

As we wait for a feature to be developped, can you please provide us with an example of how to properly use the Wiki markup (exclamation mark) in a comment. For example, if I have attached a file to a Request (let's say: picture.jpg) and I am marking the Request as Resolved, I want to email my customer a copy of picure.jpg (or the link to it): how do I do this, using the proper wiki markup? Many thanks.

i am not sure if this falls under this ticket. basically, we have implemented JIRA Service Desk using its email channel. Works OK except that if we put an attachment as part of the response to a customer support ticket, the customer will be shown a link to the actual location of the attachment in JIRA but needs to login to see it. If JSD allows public registration via its email channel, i would presume it should automatically grant access to that registered user to browse the attachments without logging in.

I fully agree with other customers that this feature is a Must-Have. Atlassian, please provide us with more information on when we can expect this feature.

For Cloud Version.

There is an addon that provides a workaround. https://marketplace.atlassian.com/plugins/com.onresolve.jira.groovy.groovyrunner

Create a script listener for the update event for your project. Include a JQL query that validates true if an attachment was added.
attachmentManager.getAttachments(issue) && changeItems.any

&& ! issue.securityLevel

configure it to send an email with new attachments. You can even include some nice html email formatting.

So now if a tech or reporter attaches a file or image the attachment will be sent as an email. I no longer notify of the update event.

After having worked with more SD programs than I can count, I am stunned that attachments for customer visibility don't work.
Stunned!
Atlassian, where do you stand on addressing this shortcoming?

Either drag n drop or embedded autocomplete would be nice.

Atlassian.. can you PLEASE show some respect for your customers and try to find a way to keep us informed when we can expect a solution for important issues like this one..

Dragon Stage 2: Could not get attachment to load. I clicked the Capture logo on four screens and the initial issue that I created failed to load. I closed all the screens and tried again and it work but it was very confusing. I would be nicer if their was a big Attach button or confirmation the attachment was captured display persistently.

I second this request. This would improve operations significantly as well in our environment. Please add this.

I'm adding another voice to this discussion as we are wanting to use Service Desk as a full end-to-end solution for service enquiries and this seems to be a sticking point. If we have to use email (or other third-party means) to send files to our customers relating to a ticket, we break encapsulation with Service Desk, introduce potential risk, add cost and it just doesn't feel 'right'. There should really be a way to have customers easily download files loaded to a ticket by Service Desk agents, and no-one should have to learn any wiki markup to do this.

If you do continue to use the embed syntax, please make it autocomplete, so when I type [ it prompts with the names of attachments.

I agree - let me know when this does become available.

I agree this is a critical feature to using this to support customers, and one that is so well implemented throughout the rest of Atlassian products (JIRA proper, Confluence, etc.) that it - from an Atlassian customer's perspective - seems so "easy"

@Shihab

+1
I totally agree Cesar. It is strange that customer can make attachments that agents can see but agents being unable to do so. For our type of business it is crucial that we can share attachments with our customers.

Take care

same here, very annoying. Please make this a drag and drop action or something.

Please Atlassian this issues is very important for my customers, when my request is a file I need to send by e-mail the file. This is not acceptable when the customer opens an issue could attach a file , and the service agent could attach a file in jira but the customer couldn't view this file.

Come on Atlassian, you are better than this. Wiki markup is not the way to communicate a file to a customer when giving support. It must be easier and faster than that.

Get this done quickly.

Totally agree! Honestly we live in a tech world now; not that hard to learn something and then use it. (Have to admit been in software since 1998 but come on people!) Okay, you can delete this comment; I have said my rant.

The emphasis here seems to be on the visibility of images, but what people are concerned about in JSD-43 is making it possible for files of any sort to be made available for the customer to download. Perhaps that can be made clearer.

The idea that attachments should be presented to the customer in the context of a comment (as explained here) does indeed address a weak point of Jira and is probably an improvement.

As for the solution, if the intention is to avoid wiki markup, then the option to add one or more customer-available attachments has to be part of adding/editing a comment itself, and part of the comment GUI.

All in all a move in the right direction, but the devil is in the details, which aren't clear yet.

-David