[Tickets #3381] "forward" handles text/alternative incorrectly

[bugs@bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/?id=3381
-----------------------------------------------------------------------
 Ticket             | 3381
 Updated By         | Chuck Hagenbuch <chuck at horde.org>
 Summary            | "forward" handles text/alternative incorrectly
 Queue              | IMP
 Version            | HEAD
 State              | Assigned
 Priority           | 3. High
 Type               | Enhancement
 Owners             | Michael Slusarz
-----------------------------------------------------------------------


Chuck Hagenbuch <chuck at horde.org> (2006-04-15 10:11) wrote:

> Please see the comment dated 2/8/2006.  The issue is it is very 
> difficult (if not impossible) to code an algorithim that 100% 
> correctly identifies what "should" be forwarded and what shouldn't.  
> IMP's previous algorithim was not 100% reliable - that is why I have 
> been playing around with other methods.

I understand where you're coming from here, but I think the previous
behavior was more intuitive for most users. The only real issue was with
multipart/alternative parts, thus the original issue in this ticket.

> My goal is to create a forward drop-down (like the current reply 
> drop-down) that has (at least) 2 options: Forward as RFC822 part and 
> Forward attachments only.  Also, to add a preference for default 
> forwarding behavior - this behavior will be used when the 'Forward' 
> navbar action is clicked (rather than any of the options in the drop 
> down).  I just haven't had a whole heck of a lot of time lately, 
> which is why this ticket has stalled lately.  But this is at the top 
> of my list of things to do (this obviously needs to be resolved 
> before IMP 4.2 so I am bumping the milestone).

I think those 2 are what is needed, and a preference matches what I remember
clients like Thunderbird providing.

With multipart/alternative + forwarding inline, I'd also be fine with just
taking the text part from the alternative part and dropping the rest. If at
some point we can be smarter and take the HTML part if we support HTML
composition, that's a bonus.