Custom Query (332 matches)

Index: email2trac.py.in
===================================================================
--- email2trac.py.in	(revision 233)
+++ email2trac.py.in	(working copy)
@@ -687,7 +687,7 @@
 			else:
 				value = field.get('value')
 				options = field.get('options')
-				if value and options and value not in options
+				if value and options and value not in options:
 					value = options[int(value)]
 
 			if self.DEBUG > 10:

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)]]

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'.