We have been running trac + email2trac successfully for a while
here. The major issues we've run into are:
- Mail loops, make sure you double and triple check your black
lists because if you don't you'll wind up with enormous trac
crippling tickets and DoS your email server. Back up your
database regularly too because sometimes it's just faster to
roll back instead of trying to crawl around in mySQL/SQLite to
remove all the ticket remnants (and we've had our SQLite DB
balloon so large most tools can't interact with it to remove the
offending ticket).
- While you can issue email responses from inside trac, this
behavior happens every time you update a ticket which makes it a
bit spammy. Even if all you are doing is changing the owner of
the ticket, everyone on that ticket will receive an email about
it, you also can't make private notes in a ticket that are only
readable by ticket managers.
- Reply To addressing is a bit bad, you can't assign reply to's
to individual components only individual projects, so even thou
we have separate email addresses that populate different
components, reply emails from the project all come from that
central email address.
- ie, the project's email address is l...@labs.com, but a
second email alias is made called labxc...@labs.com. This
will create tickets in the correct component (whatever you set
it to in the alias file) but ticket updates will come from
labX@. It's not a huge deal but it can be confusing to end
users.
- We had major spam issues but solved it by piping our email
through the institutions spam filtering appliance instead of
accepting email directly. This forwarding setup requires a few
minor tweaks but it's worth doing if you have the infrastructure
required.
- If you can strip out the HTML version of the email before
delivering it to trac this is recommended. The HTML formatting
makes trac's ticket layout look somewhere between bad and
unusable (in 0.10 which is our current install we are upgrading
to 1.x soon)
I like it for a basic setup but our ultimate goal is to split ticket
handling out to RT and keep trac as our KB system for our labs due
to needing some features that trac can't support.
-Garrett
On 9/4/2013 10:52 AM, W. Martin Borgert
wrote:
Quoting roger.oberholt...@gmail.com:
We are looking at using email2trac to
allow users to add and modify tickets. I
am curious what experience people have had with this. Not so
much how
email2trac works, but how you have managed getting users to
format messages
correctly.
No guidelines, just some experiences here.
We used to use email2trac and probably will use it again in the
company for dealing with end customers with limited technical
experience. It works very well, but has some room for improvement,
too:
1. Users tend to forget the ticket number in the subject or they
even remove it. This leads to creation of duplicates. There is
no easy merging of tickets in Trac, so this means work :~(
Possible improvements: email2trac should work on base of
message-ids in the e-mail header instead of parsing the
subject
like OpenERP. Or one could have one email address per ticket,
like in Debian (e.g. 123...@bugs.myserver.com).
2. Some users accidently use old/wrong ticket numbers in the
subject.
Tickets become a mess this way. This did happen only once or
twice.
3. There is no reply possible from within Trac. This is something
OpenERP does very nicely. One can handle the ticket completely
in
the web application, while in Trac you have to go back to your
MUA.
4. Spam was an issue for us, but we probably did not investigate
enough what to do about it.
HTH, Cheers
--
You received this message because you are subscribed to the Google Groups "Trac Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at http://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/groups/opt_out.
|
