Custom Query (332 matches)


Show under each result:

Results (16 - 18 of 332)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Ticket Resolution Summary Owner Reporter
#270 fixed Attachments of type "Text/Plain" are not attached if more than one attachment is sent bas hju@…

I'm facing a strange effect with attachments.

We use blat 2.6.2 to send logfiles from batchjobs using the "-attach" parameter. If there is only one file "file1.txt", this file of type "TEXT/PLAIN" is attached and processed fine with email2trac (means: attached to a new ticket)

I've extended the processing to send three attachments:

  • file1.txt
  • file2.txt
  • file3.dimport

All files are simple text-files

In this case, file3 is of type "APPLICATION/OCTET-STREAM" (depends on extension, i guess). Only file3.dimport is attached. The other files are ignored (no warning or error).

I changed the blat parameter to "-attacht" to attach the logs as Text-Attachments. The mail-attachments are now all of type "TEXT/PLAIN", but nothing is attached by email2trac (no warning or error)

Looking at the code, it themes clear because this attachments are explicitly excluded in def get_message_parts(self, msg):

    def get_message_parts(self, msg):
        for part in msg.walk():
            ## Save all non plain text message as attachment
            if not content_type in ['text/plain']:

Strange that a single TEXT/PLAIN attachment is processed by email2trac...

Maybe it's a solution to remove this restriction, but I think this is not restricted without reason. In older versions of email2trac, this part was handled different...

#141 duplicate Attachment with "ü" causes python error an is not attached bas hju@…

We found a problem with python-code execution if there is an german "Umlaut" (ü) in the filename of an attachment.

email2trac produces an error in the user.log of the server { Mar 10 17:00:04 ks35958 email2trac: Traceback (most recent call last): Mar 10 17:00:04 ks35958 email2trac: File "/usr/bin/email2trac", line 1249, in ? tktparser.parse(sys.stdin) Mar 10 17:00:04 ks35958 email2trac: File "/usr/bin/email2trac", line 818, in parse self.new_ticket(m, spam_msg) Mar 10 17:00:04 ks35958 email2trac: File "/usr/bin/email2trac", line 757, in new_ticket str = self.attachments(msg, tkt) Mar 10 17:00:04 ks35958 email2trac: File "/usr/bin/email2trac", line 1049, in attachments url_filename = urllib.quote(filename) Mar 10 17:00:04 ks35958 email2trac: File "", line 1110, in quote res = map(safe_map.getitem, s) Mar 10 17:00:04 ks35958 email2trac: KeyError?: u'\xfc' }

The ticket is created, but the attachment is not added.

Tracking down the error leads to an python-error in 2.4. The routine "quote", trying to encode special characters in the filename as "%<##>", returns an KeyError? with "\xfc" (ü).

However: Is there possible workaround usin another python-function?

We use a trunk-version (218) of Version 0.30

P.S.: in another environment, we are using email2trac version 0.80 with python 2.5 under windows... Under this circumstances, there is no ticket createt at all...

#57 fixed attempting to update a ticket fails, unsupported operand error bas dekimsey@…

I have an email that I am attempting to load into trac from within the command line. At the moment, the email2trac script fails with the following error:

Traceback (most recent call last):
  File "./.install/bin/email2trac", line 956, in ?
  File "./.install/bin/email2trac", line 539, in parse
    if self.ticket_update(m):
  File "./.install/bin/email2trac", line 415, in ticket_update
    tkt.save_changes(, body_text, when)
  File "/home/lendor/python/lib/python2.4/site-packages/Trac-0.11b1-py2.4.egg/trac/ticket/", line 211, in save_changes
    when_ts = to_timestamp(when)
  File "/home/lendor/python/lib/python2.4/site-packages/Trac-0.11b1-py2.4.egg/trac/util/", line 55, in to_timestamp
    diff = dt - _epoc
TypeError: unsupported operand type(s) for -: 'int' and 'datetime.datetime'

I am using trac 0.11b1 and email2trac 0.9.5.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Note: See TracQuery for help on using queries.