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'm trying to use trac+email2trac as a request tracket for the support@ email address at our company.

It mostly works, except for the following problems:

1) If the reporter answers to a notification email, that email is either sent from support@company, in which case the reply becomes a _new_ ticket, or it's sent from <other>@company, in which case it's not tracked. It doesn't seem to be possible to track replies to notifications, as replies in trac.

2) It's not possible to exclusively use trac, since for example you cannot attach files when replying to tickets. I don't want to use trac exclusively either, since my mail client is much nicer to compose mails in.

To solve these problems, I suggest something like the following scenario:

• The ticket number is put in the subject, like with RequestTracker? ("Ticket #42: Question about foo")

• A customer, bob@… has a request for support@…. He sends his question like a normal email (which pipes into email2trac)

• The company recieves a new ticket notification from trac (or email2trac), with the Reply-to header set to support@…. They reply to bobs request.

• Email2trac now gets another notification. This time it contains a valid ticket number in the subject, so email2trac can know it's a reply to a ticket, not a new ticket. The new text gets added as a reply to the ticket, and bob@… is sent the new reply as well.

• Bob has further questions, so he replies back to the ticket notification

• Bobs reply is again added as a reply in trac, and the company receives his reply

• The company this time send the final information to bob, and adds "FIXED" in the subject.

• The reply from the company is added in trac, and the ticket is closed. The reply is sent to bob.

I hope you can see the idea I have for using trac as a sort of mediator, or ticket gateway, if you will. As far as I can see, it should already be able to update tickets, although I have not successfully made this work yet.

Can you tell me what kind of work would be required to make email2trac act as outlined here? Would patches be accepted?

for some reason the run_email2trac wrapper is failing. the email2trac
script works with the same input if run as root.

$run_email2trac --project=dummy < dummy.eml
returns 254

-------- /etc/email2trac.conf -----------
[dummy]
project: /home/scdev/trac/projects/dummy
debug: 1
umask: 022
spam_level: 3
reply_all: 1
mailto_link: 0
umask: 022
email_comment: >
email_header: 0
trac_version: 0.10
enable_syslog: 1
alternate_notify_template:
drop_spam: 0
verbatim_format: 1
strip_signature: 0