Re: [Trac] email2trac use guidelines
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11.09.2013 23:13, Dimitri Maziuk wrote: On 09/11/2013 01:10 PM, Steffen Hoffmann wrote: On 11.09.2013 16:30, Dimitri Maziuk wrote: I believe the other piece of the puzzle is the ability to update /etc/trac/aliases (or whereever we put the aliases file) and run 'newalias' when a new ticket is created. And the question of whether to have this enabled per-project (or globally, or per-ticket). Do you mean some kind of subscription for (all) new tickets here? What I mean is when you create new ticket e.g. #12345, an e-mail address 12345@mytrac.myorg should materialize on your mail server. Or not. Somebody may not want a particular ticket to accept e-mail updates, hence or not. Somebody may want to be able to create new tickets via e-mail (I wouldn't want that without a filter on at least From: addresses, but someone else might) -- then you'd have to enable it on all tickets per-project or per trac instance. And so on. I see your point. However, mangling of system files like '/etc/trac/aliases' should not be considered seriously. IMHO it would be mandatory to have a static mail server configuration, that forwards *@mytrac.myorg unconditionally, and let Trac/AnnouncerPlugin (or email2trac itself?) deal with filtering. Anyway, it should be kept in one place - the Trac environment. We do not have such functionality in Trac/AnnouncerPlugin today, true. Steffen Hoffmann -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlIxZpkACgkQ31DJeiZFuHepQACeJf41Qa7TkOPMGDOQ0A/zz70+ NAYAoLESrfGUG1/ztVDIf1v0kFwywcjr =eSim -END PGP SIGNATURE- -- 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.
Re: [Trac] email2trac use guidelines
On 12 sep. 2013, at 09:00, Steffen Hoffmann hoff...@web.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11.09.2013 23:13, Dimitri Maziuk wrote: On 09/11/2013 01:10 PM, Steffen Hoffmann wrote: On 11.09.2013 16:30, Dimitri Maziuk wrote: I believe the other piece of the puzzle is the ability to update /etc/trac/aliases (or whereever we put the aliases file) and run 'newalias' when a new ticket is created. And the question of whether to have this enabled per-project (or globally, or per-ticket). Do you mean some kind of subscription for (all) new tickets here? What I mean is when you create new ticket e.g. #12345, an e-mail address 12345@mytrac.myorg should materialize on your mail server. Or not. Somebody may not want a particular ticket to accept e-mail updates, hence or not. Somebody may want to be able to create new tickets via e-mail (I wouldn't want that without a filter on at least From: addresses, but someone else might) -- then you'd have to enable it on all tickets per-project or per trac instance. And so on. I see your point. However, mangling of system files like '/etc/trac/aliases' should not be considered seriously. IMHO it would be mandatory to have a static mail server configuration, that forwards *@mytrac.myorg unconditionally, and let Trac/AnnouncerPlugin (or email2trac itself?) deal with filtering. Anyway, it should be kept in one place - the Trac environment. All must be done with your MTA configuration. In our environment we choose for: * email2trac+ticketid@surfsara.nl This functionality is in the trunk version of email2trac. The other format is also supported: * ticketid@email2trac.surfsara.nl The most MTA supports wildcard email addresses. Everthing is forwarded to our MTA and we have set the 'recipient_delimiter for postfix, see: * https://oss.trac.surfsara.nl/email2trac/ticket/297 We do not have such functionality in Trac/AnnouncerPlugin today, true. If AnnouncerPlugin also support this we have a complete setup. Via email and web interface. --- SURFsara has a new telephone number: +31 20 800 1300. Bas van der Vlies | Operations, Support Development | SURFsara | Science Park 140 | 1098 XG Amsterdam | T +31 (0) 20 800 1300 | bas.vandervl...@surfsara.nl | www.surfsara.nl | -- 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.
Re: [Trac] email2trac use guidelines
Or one could have one email address per ticket, like in Debian (e.g. 123...@bugs.myserver.com). +1. This is the interface people who use such tools come to expect. 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. That could be handy but trac can already e-mail ticket updates. I think integrating that with email2trac replies might be worth looking into instead: e.g. someone e-mails a ticket update, they automagically get on cc list. I am just back from vacation and read this email2trac thread. Message-id's are not stored in the trac database and if you submit a ticket via the web interface there is no knowledge about the message id. what we want is a flexible reply to address that can handle basically these 2 formats: 1. bugnumber@email2trac.surfsara.nl 2. email2trac+bugnumber@email2trac.surfsara.nl See ticket: https://oss.trac.surfsara.nl/email2trac/ticket/297 for explanation. Email2trac supports this, but i also want to be able to submit tickets via the web interface, but TRAC/AnnouncerPlugin does not support setting a another reply-to address. There is an ticket with a request for this feature: * https://trac-hacks.org/ticket/10044 I have downloaded the AnnouncerPlugin and tying to implement this feature, but i encountered some issues with it. regards --- SURFsara has a new telephone number: +31 20 800 1300. Bas van der Vlies | Operations, Support Development | SURFsara | Science Park 140 | 1098 XG Amsterdam | T +31 (0) 20 800 1300 | bas.vandervl...@surfsara.nl | www.surfsara.nl | -- 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.
Re: [Trac] email2trac use guidelines
On 2013-09-11 05:51, Bas van der Vlies wrote: I am just back from vacation and read this email2trac thread. Message-id's are not stored in the trac database and if you submit a ticket via the web interface there is no knowledge about the message id. what we want is a flexible reply to address that can handle basically these 2 formats: 1. bugnumber@email2trac.surfsara.nl 2. email2trac+bugnumber@email2trac.surfsara.nl I believe the other piece of the puzzle is the ability to update /etc/trac/aliases (or whereever we put the aliases file) and run 'newalias' when a new ticket is created. And the question of whether to have this enabled per-project (or globally, or per-ticket). Dimitri -- 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.
Re: [Trac] email2trac use guidelines
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11.09.2013 16:30, Dimitri Maziuk wrote: I believe the other piece of the puzzle is the ability to update /etc/trac/aliases (or whereever we put the aliases file) and run 'newalias' when a new ticket is created. And the question of whether to have this enabled per-project (or globally, or per-ticket). Do you mean some kind of subscription for (all) new tickets here? Steffen Hoffmann -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlIwshEACgkQ31DJeiZFuHdFqwCgsPobQPL/oZ792shxJV76UE9z K1sAoJ6ZEBuvWDDDhqPwML8MmhR6+2w+ =jK0J -END PGP SIGNATURE- -- 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.
Re: [Trac] email2trac use guidelines
On 09/11/2013 01:10 PM, Steffen Hoffmann wrote: On 11.09.2013 16:30, Dimitri Maziuk wrote: I believe the other piece of the puzzle is the ability to update /etc/trac/aliases (or whereever we put the aliases file) and run 'newalias' when a new ticket is created. And the question of whether to have this enabled per-project (or globally, or per-ticket). Do you mean some kind of subscription for (all) new tickets here? What I mean is when you create new ticket e.g. #12345, an e-mail address 12345@mytrac.myorg should materialize on your mail server. Or not. Somebody may not want a particular ticket to accept e-mail updates, hence or not. Somebody may want to be able to create new tickets via e-mail (I wouldn't want that without a filter on at least From: addresses, but someone else might) -- then you'd have to enable it on all tickets per-project or per trac instance. And so on. -- Dimitri Maziuk Programmer/sysadmin BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu signature.asc Description: OpenPGP digital signature
Re: [Trac] email2trac use guidelines
Quoting Dimitri Maziuk dmaz...@bmrb.wisc.edu: or forget if it was '#number' or 'number' or what and pick the wrong one... In fact, it is '#number:' - how often did I forget the trailing colon? Message IDs don't work. For instance the version of thunderbird I'm writing this in has reply to list but not new message to mailing list. So people often hit reply to list to start a new thread. Then you have message ID for one thread and subject for another -- now think thread == ticket. This is a danger, indeed. Maybe one could combine message-id and subject, such as message-id is ignored if subject differs (after removing all the the Re, Fwd, AW, #31572;#22797;, ... prefixes). 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.
[Trac] email2trac use guidelines
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. I think we are mainly looking at letting users create tickets and add and reply to comments. Adding a new ticket seems to be rather straight forward. Just send an e-mail where the subject is not a reference to an existing ticket and a new ticket will be created. The body of the e-mail is the description in the ticket, right? Is there a way to get the sender added to the Cc list of that created ticket? Not replacing the default - adding to it. Adding and replying to comments is more confusing. If a user gets an e-mail from Trac that a ticket has had some change and they want to comment, must they have a field like @comment: My 2cents? Are there amy things to consider when Trac sends e-mails? For example, there is a footer that tells the URL to the message and a few other things. Wouldn't that be in the comment if it is left in the reply? So must the user strip away stuff like this? Although the docs for email2trac say alot, some simple things are less than clear to me. Any advice or experiences is welcome! -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholt...@ramboll.se Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- 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.
Re: [Trac] email2trac use guidelines
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.
Re: [Trac] email2trac use guidelines
On 9/4/13, W. Martin Borgert deba...@debian.org 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. [...] 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). AFAICT both suggestions are valid . FWIW , I prefer it to work the Debian way . However under certain circumstances this might not be possible to deploy , but I guess it'd be possible to toggle this behavior on/off considering some configuration ... ? [...] @robert : About replies , I've noticed that other systems include some «tags» in the message with the purpose of delimiting comment boundaries . AFAICT this feature is not available in email2trac (... cmiiw ...) and would be nice to have. Other features like triggering workflow actions and updating fields might be more complicated to handle . -- Regards, Olemis - @olemislc Apache™ Bloodhound contributor http://issues.apache.org/bloodhound http://blood-hound.net Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: Apache™ Mesos se gradúa de Apache™ Incubator - http://goo.gl/fb/fI4wW -- 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.
Re: [Trac] email2trac use guidelines
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.
Re: [Trac] email2trac use guidelines
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04.09.2013 17:07, Garrett McGrath wrote: 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 You're rather detailed explanation ends with this unclear statement. Maybe it's just me, but would you be so kind as to name or describe roughly, what these missing features are, please? Steffen Hoffmann -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlInV7MACgkQ31DJeiZFuHenOgCdHnNCcK5uPctcNSrhIv2zmV63 BPoAni3A5DK9PcQR6MG6h71vgKOgoAJY =WEyk -END PGP SIGNATURE- -- 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.
Re: [Trac] email2trac use guidelines
Steffen, Fundamentally we've just out grown trac's ticket handling for what we were using it for. We aren't using trac for project management (in this case) we are using it as a knowledge portal and helpdesk system for our Institutes labs. We've grown since we set this up from around 25 high activity users to over 70 and will be moving to well over 100 in the next year or two. RT gives us a few benefits in that level environment that we don't get in Trac. Things like private ticket comments, suppressing ticket emails, templated behavior, shared queues, centralized management with seperate queues (which we currently have to accomplish by making separate projects for separate queues), it's handling of ticket updates via email are very powerful as well as it can use a number of metrics to determine if a ticket is actually an update instead of a new ticket. It also lets us auth against apache's auth framework (and by proxy our institutions CASAUTH system). We would also like to take the ticket system somewhat out of the public eye of our users, separating it from the KB system makes that easy as we can restrict the people allowed to see the web interface to only those that actually need to interact with it instead of allowing anybody with a general login to read all the tickets available. It's also the standard system for many other groups on campus, so we are moving in that direction instead of continuing to maintain a separate island of technology. Beyond that it's a learning experience for me as I've never setup RT before. -Garrett On 9/4/2013 11:54 AM, Steffen Hoffmann wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04.09.2013 17:07, Garrett McGrath wrote: 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 You're rather detailed explanation ends with this unclear statement. Maybe it's just me, but would you be so kind as to name or describe roughly, what these missing features are, please? Steffen Hoffmann -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlInV7MACgkQ31DJeiZFuHenOgCdHnNCcK5uPctcNSrhIv2zmV63 BPoAni3A5DK9PcQR6MG6h71vgKOgoAJY =WEyk -END PGP SIGNATURE- -- 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.
Re: [Trac] email2trac use guidelines
On 09/04/2013 09:52 AM, W. Martin Borgert wrote: 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 :~( or forget if it was '#number' or 'number' or what and pick the wrong one... Possible improvements: email2trac should work on base of message-ids in the e-mail header instead of parsing the subject like OpenERP. Message IDs don't work. For instance the version of thunderbird I'm writing this in has reply to list but not new message to mailing list. So people often hit reply to list to start a new thread. Then you have message ID for one thread and subject for another -- now think thread == ticket. Or one could have one email address per ticket, like in Debian (e.g. 123...@bugs.myserver.com). +1. This is the interface people who use such tools come to expect. 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. That could be handy but trac can already e-mail ticket updates. I think integrating that with email2trac replies might be worth looking into instead: e.g. someone e-mails a ticket update, they automagically get on cc list. 4. Spam was an issue for us, but we probably did not investigate enough what to do about it. Well, if you have #1 you'll probably have to run your own smtpd anyway, that's where you can add spamassassin and/or whatever. -- Dimitri Maziuk Programmer/sysadmin BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu signature.asc Description: OpenPGP digital signature
