Custom Query (332 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (232 - 234 of 332)

Ticket Resolution Summary Owner Reporter
#107 fixed email2trac cant format email sent by postfix bas Florian
Description

Hi

I'm trying to run email2trac with postfix. It kindof works, but just kindof.

When I test it with

mail tracproj < msg.txt

a new ticket is created, but it is not formated at all. The whole email, including headers and mime definition is part of the description of the new ticket. and there are no attachement. The body looks

From ...  Wed Mar  8 15:29:17 2006
Return-Path: <...>
X-Original-To: ...
Delivered-To: ...
Received: from surfboard.ka.sara.nl (surfboard.ka.sara.nl [145.100.6.3])
	by localhost.localdomain (Postfix) with ESMTP id 506702800682
	for <...>; Wed,  8 Mar 2006 15:29:17 +0100 (CET)
Received: from [145.100.6.134] ([145.100.6.134] RDNS failed) by
	surfboard.ka.sara.nl with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 8 Mar 2006 15:29:17 +0100
Message-ID: <440EEA39.6070200@sara.nl>
Date: Wed, 08 Mar 2006 15:29:13 +0100
From: Bas van der Vlies <....>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: ...
Subject: Test123
Content-Type: multipart/mixed; boundary="------------070800080005060203060809"
X-OriginalArrivalTime: 08 Mar 2006 14:29:17.0140 (UTC)
	FILETIME=[AE40B940:01C642BC]

This is a multi-part message in MIME format.
--------------070800080005060203060809
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Test1234
Test1234

When I try to create a ticket with

email2trac --project=tracproj < msg.txt 

the email is created and formated just fine.

I run it with mta_user=nobody and trac_user=root (I know, it is not the best way to run it with root...)

Any idea what I missed or what I could have done wrong?

Thanks Florian

#106 fixed More versatile support for Mac attachments bas ben@…
Description

I implemented three new configuration options, having to do with treatment of attachments that include Mac-specific data.

The attached diff is relative to the changes I submitted in #105.

binhex

The BinHex encoding format is deprecated (in favor of AppleDouble MIME, see RFC 1740), but some older clients might still be using it. A file encoded with BinHex is annoying to decode unless you are on a Mac.

The binhex option can be set to one of:

  • 'keep', in which case attachments encoded with BinHex will be included in the ticket
  • 'warn', in which case attachments encoded with BinHex will be ignored, but a warning message to that effect will be included in the ticket description
  • 'drop', in which case attachments encoded with BinHex will be silently ignored

The default is 'warn'.

applesingle

Same options and meaning as for binhex option above.

appledouble

The AppleDouble encoding format is the recommended way to include Mac-specific data in a MIME message, as per RFC 1740. A file encoded with AppleDouble can easily be presented usefully on all platforms.

The applesingle option can be set to one of:

  • 'keep', in which case both the platform-neutral data and the Mac-specific data will be included in the ticket (as two separate attachments)
  • 'warn', in which case only the platform-neutral file data will be included in the ticket. Mac-specific data will be left out, but a warning message will be included in the ticket description.
  • 'strip', in which case only the platform-neutral file data will be included in the ticket. Mac-specific data will be left out with no warning.

The default is 'warn'.

#105 fixed Better support for inline attachments and multiple body parts bas anonymous
Description

Right now, email2trac assumes that the first text part of a message is its body, and that everything else is an attachment.

With modern email clients, it's possible to create a message that has an attachment in the middle of its body. MIME represents this kind of a thing as a text/plain part followed by an image type followed by another text/plain part.

When this happens, email2trac produces a ticket whose description contains only the first part of the body, and gives it two attachments: one for the image, and one for the second part of the body. This is wrong.

The patch that I am attaching implements the following features

Proper support for multiple body parts

If a message's body is broken up into several pieces (by attachments in the middle of the message), the ticket's description is set to the entire body, not just the first part

For example, from an email like this:

some text
<some image>
more text

the ticket that is created will have "some text" and "more text" in its description

Links to attachments inside the ticket description

[attachment:filename] links are automatically placed inside the ticket description, so that message text can clearly refer to them.

For example, an email like

I opened this file in your app:
<my file>
and I got the following error dialog:
<image>

will generate a ticket like this:

I opened this file in your app:

[attachment:"my file"]

and I got the following error dialog:

[attachment:"image"]

Inline image attachments

If an attachment is of type image/* and its Content-Disposition is inline, then a Trac Image macro is placed inside the ticket description in the appropriate place, so that the resulting ticket has the image inline where it belongs in the text.

The same email as in the previous example, if the image is inline, will result in:

I opened this file in your app

[attachment:"my file"]

and I got the following error dialog:

[[Image(image)]]
Note: See TracQuery for help on using queries.