Create and respond to tickets via email

[kurt]

I'd like to be able to create and respond to tickets using email, since I tend to do quite a bit of work in a disconnected state and it would make for an easy way to queue up tickets.

In theory, it would work something like this:

1. I create an email address (like trac-ticket@…)
2. Trac checks a pop mailbox every so often for new email
3. New emails are turned into tickets

This is relatively straightforward. When emails come in, they could be assigned default values for the various properties. Ideally, these could be specified on a per email basis: trac-feature@… could get various default values I've specified to match features requests, while trac-bug@… could have default values that match bug reports.

The second portion of this would involve parsing and applying email responses to the appropriate tickets. When I respond to a trac email notification, it could parse out the new response and put it as a ticket response. This would be divine, and would totally make my life easier.

Our users have been trying to respond to email notifications on tickets, since this is the way our real "ticketing system" works for things. I've been forced to manually handle those emails and do essentially what Python could be doing for me.

[Emmanuel Blot]

Have you checked out ​http://trac-hacks.org/wiki/EmailtoTracScript ?

Anyway, Trac Core is a web application, so this kind of feature should be implemented as plug-in or the like, I don't see such a feature implemented in Trac Core…

[kurt]

Nope, I haven't seen that, I'll check it out. I even looked but couldn't find it. :)

[sid]

Replying to eblot:

I don't see such a feature implemented in Trac Core…

Agreed. Reopen if you really think it belongs in Trac core, but the plugin should work for most people.

[anonymous]

Replying to sid:

Replying to eblot:

I don't see such a feature implemented in Trac Core…

Agreed. Reopen if you really think it belongs in Trac core, but the plugin should work for most people.

I think this should be part of the trac core. Disabled by default, but you should get this out of box.

[shulegaa@…]

I agree that this should go into the box - via something akin to Python's 'Batteries Included' philosophy - but NOT because it makes all that much (software) architectural sense. This is more of a product packaging ('sex appeal') issue. Permit me to explain. Yes, tl;dr.

Today, it can take a sys admin type days to install trac, add dozens of plug-ins, and then configure the whole lot. Trac's success, and Trac's plug-in bonanza, makes for one heck of a adoption barrier. Sure, the Trac project isn't, perhaps, too motivated to broaden it's appeal. There no money in that. Bummer. Reality is highly over-rated. It sure would be nice to get past the 'lots-of-assembly-required' packaging level.

This reminds me of the PostgreSQL's principled stand against making any particular sort of 'replication' part of the PostgreSQL core. Architecturally, any sort of replication should all be layered atop the DB core (and thus leverage the DB core's rich extensibility interfaces/hooks).

Then reality bites. Firms like RedHat were investing $$$ in PostgreSQL development on the one hand, and then installing MySQL for internal purposes on the other. Why? Because 'replication' was easier to deploy as part of core, more-trusted as part of core, etc. This finally drove enough PostgreSQL developers crazy enough that they forsook their architecture-fidelity-first point of view. After all, RedHat employed a lot of them!