After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 487922 - Sometimes evolution does not recognize attachments
Sometimes evolution does not recognize attachments
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Mailer
2.12.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: Milan Crha
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2007-10-18 14:37 UTC by Milan Crha
Modified: 2007-10-30 09:10 UTC
See Also:
GNOME target: ---
GNOME version: 2.19/2.20


Attachments
proposed evo patch (2.89 KB, patch)
2007-10-18 17:32 UTC, Milan Crha
committed Details | Review
A Picture speaks a Thousand words (61.51 KB, image/png)
2007-10-26 10:15 UTC, Sankar P
  Details

Description Milan Crha 2007-10-18 14:37:22 UTC
Forwarding from a downstream bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=236396

--------

Description of problem:
In some emails I have received recently which contained attachments,
evolution only identified them as ``unknown attachment'', instead
of PDF, etc. 

Version-Release number of selected component (if applicable):
beagle-evolution-0.2.13-1.fc6.i386.rpm
evolution-2.8.3-2.fc6.i386.rpm
evolution-data-server-1.8.3-4.fc6.i386.rpm
evolution-data-server-devel-1.8.3-4.fc6.i386.rpm
evolution-sharp-0.11.1-10.fc6.i386.rpm
evolution-webcal-2.7.1-6.i386.rpm

How reproducible:
It seems to be correlated with senders using Apple Mail (all examples use
Apple Mail 2.752.3 or 2.619). I am not sure if all Apple Mail emails with
attachments have this issue, and older ones may work better, so that it might 
be a recent regression. (Specifically, the cutoff seems to be around the end
of January / beginning of February; there was an evolution update on
Feb. 12).

Steps to Reproduce:
Not clear how to reproduce this directly.
  
Actual results:
Unreadable attachments.

Expected results:
Readable attachments.

Additional info:
I can provide sample emails which cause problem.

--------

Downstream bug contains promised test email in
https://bugzilla.redhat.com/show_bug.cgi?id=236396#c8
Comment 1 Milan Crha 2007-10-18 17:32:01 UTC
Created attachment 97435 [details] [review]
proposed evo patch

for evolution;

I realized that it shows as attachment the whole multipart, so I changed it to traverse the hierarchy of message parts and appropriately export it as attachments. See comments in changelog for further info.
Comment 2 Srinivasa Ragavan 2007-10-26 06:34:51 UTC
Sankar, can you review this for 2.21.1?
Comment 3 Sankar P 2007-10-26 10:12:20 UTC
With this patch, if there is a html-text part and a plain-text representation of that as well, And if the plugin preference is to "prefer plain text". Then you will get two attachments, the original attachment + the .html attachment. I am not sure if this will be a desired behavior. May be we can skip the .html part as the plain-text rep. is already displayed.

Comments ?
Comment 4 Sankar P 2007-10-26 10:15:22 UTC
Created attachment 97904 [details]
A Picture speaks a Thousand words
Comment 5 Milan Crha 2007-10-26 13:06:15 UTC
This was my intention. This is same only for your test case. For couple of other mails it is different. I saw some mails with an info "This mail should be viewed as HTML mail, click here to see proper version" in plain-text part, and the link targeted somewhere on the net. With this patch, you can see it when you want.

It should be also mentioned, the html attachment isn't shown inlined, by default (it's forced in a patch), so when you open the patch, then you just see it as other collapsed attachment. Which is good, I think.

You can save that attachment too, but if you skip it, then you cannot.
Comment 6 Sankar P 2007-10-30 09:03:07 UTC
Sounds explanatory. Accepted. Please Commit.
Comment 7 Milan Crha 2007-10-30 09:10:10 UTC
Committed to trunk. Committed revision 34452.
Committed to stable. Committed revision 34453.

(Sankar approved also to stable on IRC).