Email tickets to Trac

[daniel]

A MTA filter to receive tickets via email.

Case: Emailing trac-bugs@… should automatically create a ticket from the email.

It should take Trac Message-ID headers into account to recognize replies to ticket notifications. If an email is a reply to a ticket notification, its contents should be added as a comment to the ticket.

[daniel]

Not critical. In the 2.0 redesign we can give email a better thought than a simple add-on.

[Christopher Lenz]

#1162 has been marked as duplicate of this ticket.

[Matthew Good]

#1476 has been marked as a duplicate of this ticket.

[Matthew Good]

This was actually fixed months back in [1261]

See source:/trunk/contrib/emailfilter.py#latest

[Simon Litchfield <simon@…>]

Yes, 1261 added support for email creating NEW tickets. However, it doesn't read headers to recognise when an email is actually a reply to an existing ticket - in which case, it should add the contents of the reply as a comment - as the original ticket description points out.

[Simon Litchfield <simon@…>]

See here ​https://subtrac.sara.nl/oss/email2trac

[anonymous]

Replying to Simon Litchfield <simon@…>:

See here ​https://subtrac.sara.nl/oss/email2trac

Follow that project to ​this page, and you'll see that it parses for creation of new tickets, but does not add comments to an existing ticket.

Further, it requires mastering a query language written into the subject line with extremely specific params and values, in order to work. not user friendly. We don't want trac users to have to read a manual in order to be able to comment on a ticket via e-mail.

[Remy Blank]

Nevertheless, this can be implemented completely separate from Trac core, and is probably only useful to a handful of people, so it's still a "wontfix". Feel free to suggest improvements to Simon directly.

[anonymous]

I am afraid that creation tickets from e-mail is a must-to-have feature nowadays. It it very widespread. And, alas email2trac plugin does not support working with multiple projects hosted in one trac installation.
I would like propose using embedded pop3 client to fetch mails from different mailboxes and create tickets in associated with them projects.
At least, what about stand-alone Python script (+ ini file) to be run by cron for the purpose?

[sergey-miryanov@…]

I'm vote up.

[anonymous]

me too

[anonymous]

me too, tickets have to be collected in a to order category

[anonymous]

we also have VERY "non-technicals" who would use the ticket system if it could be done by mail

[anonymous]

This side we have trac being used for non-developmental tasks and I intend to use it instead of OTRS which DOES have an email to ticket system, but as everybody but me uses Trac, I have to adopt Trac… So I might be forced to look into this…

[anonymous]

Replying to anonymous:

I am afraid that creation tickets from e-mail is a must-to-have feature nowadays. It it very widespread. And, alas email2trac plugin does not support working with multiple projects hosted in one trac installation.
I would like propose using embedded pop3 client to fetch mails from different mailboxes and create tickets in associated with them projects.

me too. Trac already had Email Notification. The notification email's subject is format by ticket_subject_template in trac.ini. maybe Trac could parse a reply email and add a comment to a ticket.

It is stupid to receive a mail and login Trac to comment the ticket.

At least, what about stand-alone Python script (+ ini file) to be run by cron for the purpose?

[anonymous]

producteev has a good syntax for this and it is a great feature. vote up as well.

[anonymous]

also very interested in this feature. we have a number users that are mobile and interacting w/ trac via mobile phones. even if the feature only added comments to existing tickets only, that would be a great addition.

[Christian Boos]

#10053 was closed as duplicate.

[anonymous]

Me too — for a ticketing system to be useful it has to be able to interact with users of whatever the ticket is being logged against.

[Floris Lambrechts <floris.lambrechts@…>]

It seems this functionality is provided by email2trac: ​https://subtrac.sara.nl/oss/email2trac

[shulegaa@…]

email2trac looks promising … but really … it seems as if Trac needs a dose of 'batteries included' philosophy.

No, Trac doesn't need to compromise it's software architecture. It shouldn't. Not one bit. I just LOVE trac!

Still, the barrier to adoption should come down a bit. I've just installed a couple of dozen plug-ins. I've had to discard about dozen others that didn't work. Some plug-ins work, alone, but have conflicts with others. The amount of time spent debugging just the plug-in interactions makes me fervently hope that a LOT more plug-ins get sucked into Trac (core). DARN. Flexibility (and extensibility) need not come at such a high price!

Talk about 'some assembly required' …

[macke@…]

Indeed. It's like IKEA, but without the wrench and half the parts missing.

I had seriously hoped this would be in there.

Time to fork Trac into "UsefulTrac" or something.

[anonymous]

Replying to macke@…:

Time to fork Trac into "UsefulTrac" or something.

I don't want to promote this ticket as a place to discuss this further since the MailingList is more appropriate, but I will just say that there are various Trac derivates and distributions such as BitNami, BloodHound and AgiloTrac (see TracDerivatives), for those desiring a more bundled solution as opposed to the building blocks that Trac and Trac-Hacks offer.