Images in tickets become broken when new comments contain images | Community
Skip to main content

Images in tickets become broken when new comments contain images

  • May 10, 2021
  • 3 replies
  • 0 views
W

Hi,

I've reviewed the following community posts but the issue I am facing doesn't seem to be resembling what is described there:

This is a description of my issue:

  • My customer creates a ticket through the web interface and embeds images in the ticket
  • As an I agent I can see these images in the ticket
  • My customer then adds a comment to the ticket and that comment also includes images
  • The images that were visible upon ticket creation now appear broken 

The browser-developer console shows these errors and warnings for the initial images:

Failed to load resource: the server responded with a status of 404 () https://I_removed_this.zendesk.com/attachments/token/JUGZdOl12q9yocFNH1gl2n9pN/?name=mceclip5.png 

DevTools failed to load SourceMap: Could not load content for https://static.zdassets.com/agent/assets/react/js/async.commons.ac4de86627da36097.chunk.js.map: HTTP error: status code 403, net::ERR_HTTP_RESPONSE_CODE_FAILURE

I haven't figured out if this is a size limitation on the number or size of the pictures that can be embedded into a ticket.

My attachment manager is displaying 8 attachments totaling to roughly 28 MB.

      3 replies

      J
      • Juraj12
      • May 27, 2021

      Hello @Wouter Van Eetvelde,

      What is happening in such cases is that somebody was referencing external resources, and not actually attaching the images into the tickets.

      In such tickets, the users have been copy/pasting the sources to external sites and that's why it is stored in such a form:


      https://subdomain.zendesk.com/attachments/token/xxxxx/?name=image.png

      Even though it looks like it was stored as an attachment on your instance, it wasn't.
      It was stored as an attachment reference to an external resource, not an actual attachment, and it would expire in 3 days.
      Why are the images in my Zendesk Support ticket broken?
      Attaching files to tickets via API

      The actual links to properly attached attachments look like:
      https://p20.zdusercontent.com/attachment/...

      There are only two ways how to store this in the attachment storage:
      1. You may download immediately the attachments and store them in the ticket yourself.
      2. Or you may ask the end-users to use the attachment upload button when using the ticket form or email, and not copying it from an external resource like a website.

      Some other providers might be keeping references to external sites, but Zendesk, unfortunately, doesn't and saves it as an attachment reference.
      There also is no road map as of now that this would change in the future.

      Hope that answers it.

      W
      • Wouter11
      • Author
      • May 31, 2021

      Absolutely, thanks for responding. This explains the current behavior

      Can you share the idea behind the 3 day caching? In my case, tickets typically 'live' for a couple of weeks and the 3 day caching is very low. As a product feature, would it be feasible to add a setting that controls this caching behavior so that customers get blocked from uploading that data expires after 3 days

      Beto11
      • Beto11
      • June 1, 2021

      Hello Wouter Van Eetvelde, thanks for replying!

      Three days is the time it takes the attachment API token to expire if it is not attached to a ticket. Besides being a good combination of enough time to see the attachment, but not too long so that it becomes a security risk.

      We do have more documentation on this topic, like our API documentation regarding uploading files that might have some more info about this: Zendesk API: Attachments. 

      Of course, you are more than welcome to create a Feedback Post on our Community regarding this request. The more traction this gets, the more chance there is for our Developers to consider implementing this solution.

      I hope this was helpful!

      Terms & ConditionsCookie settingsAccessibility statement