I've run some basic tests, and everything seems to work. I've merged this into
trunk. 

-- 
Robert

On 2008-09-08 19:55, Chris Abraham wrote:
> Rob,
> Congrats on tackling this problem.  It always seemed so daunting to  
> me :)
> 
> I think towards the end of this week I'll have some time to take a  
> look at this and do some testing if you want.
> 
> Chris
> 
> 
> On Sep 8, 2008, at 7:31 PM, Robert Marianski wrote:
> 
> > I've been attempting to resolve the listen issue where if a message  
> > has
> > any attachments on it, then the footer does not get attached to the
> > message appropriately. The reason behind this is that we simply just
> > tacked on the footer to the bottom of the message, regardless of the
> > message type. This will work for messages that are just plain text,  
> > but
> > it fails if a message has any attachments or if there is a transfer
> > encoding set.
> >
> > The branch with my refactoring is here:
> > https://svn.plone.org/svn/collective/Products.listen/branches/ 
> > footer-refactor
> >
> > I've pretty significantly modified the way listMail works. listMail is
> > the function that handles sending out messages to the list, so it's
> > pretty key. The major difference is that instead of dealing with  
> > vanilla
> > strings the way the previous code did, I create an email.Message  
> > object,
> > and work with that throughout the function.
> >
> > Where this starts to get complicated is that a message can contain any
> > number of parts, which I've found can contain multiparts themselves.
> > Each part can contain its own charset encoding and transfer encoding.
> > And we should only be adding in the footer to the attachments that are
> > meant to be displayed in mail clients.
> >
> > It would have been extremely difficult to add in this functionality
> > interacting with just strings, which is why I chose to restructure
> > things a bit and use a rich message object instead.
> >
> > Anyway, long story short is that I think I have it dialed in. I have
> > some tests for it, which I think cover most of the important cases.  I
> > haven't done too much testing ttw however.
> >
> > It would be great if somebody that had some spare time could review  
> > the
> > code on the branch. I'll welcome all criticisms, especially here,
> > because the function is pretty core to listen. If there are no
> > objections, I'd like to merge this to the trunk pretty soon because it
> > resolves a few user facing issues:
> > http://trac.openplans.org/listen/ticket/2
> > http://trac.openplans.org/listen/ticket/27
> >
> > -- 
> > Robert
>