Custom Query (332 matches)

To whom it may concern:
    I'm looking at modifying the email2trac script to enable it to
handle a 'category' flag.  Specifically we are using Trac as a data
portal for our users and are exploring using the ticket system to
track
help requests to make life easier for our users (quick referrence to
past issues and etc.).  I'm thinking that the milestones system would
be
an easy way to segregate our emailed tickets automatically.  eg. if we
get a feature request for our calendar that goes to 1 email, and
general
help to a second email address, these simply populate the same ticket
system in trac but with different milestones attached to them (or
components as that would be nice to split things up with as well).  So
my question is has anyone does this before, and do I just need to
modify
the email2trac.py program or do the .c and .h files get modified as
well.
-Garrett McGrath

I am trying to set up email2trac in our multi-project trac environment by piping incoming mails through a php script which then calls email2trac with the correct project id. The only problem: email attachments are not being attached to tickets. Adding an attachments to a ticket manually works. Executing email2trac with debug option reveals that attachments of mails are being parsed and created in the tmp folder.

Last log entry lines:

2016-11-17 13:17:33,867 email2trac 182: writing body to /tmp/182xZk6af.email2trac.body

2016-11-17 13:17:33,867 email2trac 182: function debug_attachments

2016-11-17 13:17:33,867 email2trac 182:          part0: Content-Type: application/pdf

2016-11-17 13:17:33,867 email2trac 182: writing /tmp/182xZk6af.email2trac.part1.pdf: filename: st-oktober.pdf

The file exists and is readable by the apache user (which is executing the email2trac command)

But the ticket itself has no attachment and the link in the description points to an invalid/missing attachments. Looking at the projects db, the attachment table doesn't contain an entry for the attachment.

Any ideas/suggestions where or what the problem might be?

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