Custom Query (332 matches)

In our environment we had the need to block a specific attachment. I didn't see the ability to do it with existing config so I wrote a customization. Sending it along in case it might be useful to others.

Note that our environment is a bit older. As such this patch was taken against [615].

This adds a parameter to the config file. It is a comma-separated list of filenames to ignore. Could easily be converted to regex.

ignored_attachments: badfile.zip

I've installed email2trac 0.13 and am using Trac 0.10.4.

It exactly the utility I need and the fact it can be run from the command line is great as I'm not allowed to use mail aliases.

Email notification works fine for tickets created and updated via Trac web interface.

email2trac correctly enters/updates emails into the Trac system, but when it comes to emailing the notification it falls over while validating the smtp_from address specified in the trac.ini [notification] section.

$ ./email2trac --project=cms < test_msg.txt
TD: Failure sending notification on creation of ticket #66: {u'f.r.user@reading.ac.uk': (550, 'Verification failed for <no-reply@reading.ac.uk>\nUnrouteable address\nSender verify failed')}

Is there a way I can stop email2trac from sending updates to the smtp_from address? The address I use is an outgoing email address only. And is a way of persuading our Helpdesk users to use the Trac interface and stop doing an email reply.

Trac itself has no problems with me doing this.

Alternatively, can you point me in the right direction so I might be able to modify the email2trac script to stop it trying to email the stmp_from address? I can't see where the list of email addresses is assembled.

Thanks. Rosalyn

What happens:

When creating tickets, email2trac sets the default values for ticket attributes, including the "resolution" attribute. The default value for the "resolution" attribute is "fixed". This leads to the rather strange effect of a new ticket being displayed as: "Ticket #<num> (new defect: fixed)"

What should happen:

email2trac does not set the "resulution" attribute when creating new tickets (that's what trac does when using the web interface). After all, the ticket is not resolved yet. The ticket will then be displayed as: "Ticket #<num> (new defect)