Discourse mail interface / user-uploaded contents


#1

Hello anybody,
a small complaint about Discourse mail-only usage; In a message
yesterday "aszlig" upload a small image (1) that appear via mail as

![Jelly_cc11|300x200](upload://bs9Pdkj5ZTH75N5BrHFjireVP60.jpeg)

so not a clickable link to see on the web nor as an attachment
to the mail itself...

Can this Discourse/mailUI behavior be fixed or it's a limitation/bug
be fixed upstream?

Thanks,

-- Ingmar

(1)
thread: [Nix community] - [Announcements]
      NixOS 18.09 Jellyfish: to be forked off in a month
      
Message-ID: topic/596/2170@discourse.nixos.org or via web
  NixOS 18.09 Jellyfish: to be forked off in a month

right below "Something like this but without actually sucking [...]"


#2

@zimbatm probably knows where to go with this problem.


#3

I received an email for this thread and the image was embedded (see below).

@xte what email client are you using, is it opening Text or HTML emails?

Generally I don’t think that we will be able to MIME-embed the images as it would require to change Discouse. If you really want this feature then it’s best to talk upstream at https://meta.discourse.org/



#4

Hy, thanks for the quick replay,

I received an email for this thread and the image was embedded (see below).
@xte what email client are you using, is it opening Text or HTML emails?

notmuch-emacs, normally it render mime/html properly with shr, but
your suspicions are right: if I open the hidden html/mime part I
see a working link… My config problem then…

Sorry, I do not take a look carefully enough before posting

– Ingmar


#5

Well, if it could send the correct link in the text/plain it’d still be better, I think :slight_smile: (hit the same issue, and I don’t really plan on asking my email client to parse HTML)


#6

Agreed, I had glossed over the fact that the URL is actually not pointing to the actual image.

I think the purpose was to be able to dynamically replace those URLs. For example if the assets are stored on S3 and you want to avoid third-party linking this allows to generate signed URLs with an expiration.

In this instance it looks like the images are served directly through discourse though so this shouldn’t be a problem. This should be reported upstream but they closed the issues in https://github.com/discourse/discourse