Jason, There are many ways to deal with this and they depend upon your internal practices for issue management.
The way you describe a possible solution is very close to the way people are already auto-closing Nagios tickets. It's definitely worth a look to see the effort to modify that code to specifically fit your situation. This way your users can continue on in blissful ignorance. You could also modify your auto response template to notify The cc's as well as the requestor. You might need to train the users to "notice" that they were cc'd on a ticket and they should only reply through the ticket response email. Less work for you but requires user training/caring. Another option is to use the email command extension and train the users to add a cc via an email command in their original request. You would still need to modify the auto reply template but at least this way there is nothing for someone to reply to other than the rt generated email. I suppose the final solution would auto insert the appropriate cc depending the requestor. This obviously requires a decent amount of coding and a way to maintain that information (AD could be the answer). However less required of your users so they are almost back to their bliss state. Hope that gives you some options. Mike On Oct 3, 2011, at 7:21 PM, Jason Marshall <[email protected]> wrote: > Surely this is something a lot of you deal with... > > User sends our support queue an email, and cc:'s her supervisor so he gets > added as a CC. > > Ticket is created, all's well. > > Supervisor replies to the original (non-rt-generated) message he was cc:ed > on, leaving our support queue in the recipient list, which seems like a good > idea. > > Second ticket is created because the subject lacks the [queue #xxx] at the > beginning. > > User replies to her supervisor's email, which is a direct reply to her. Still > no [queue #xxx] in subject, rt still cc:ed. > > Third damned ticket is created. > > And so on and so on. > > How can this be avoided? > > Obviously, not replying to the non-rt-generated email is the right answer, > but we all know that's not going to be advice that's followed religiously. > Most of our users are not "power users" and even those who are won't likely > remember to do that all the time. > > Is there a magic flag that can be turned on that prevents this kind of > behavior by perhaps stripping the re: and comparing the subject to tickets > that have been opened somewhat recently, or maybe it could notice the subject > is the same as a ticket that has the replier as originator or cc already? > I'm really stretching here... Failing that, how the heck do you deal with > this?? > > Thanks! > > PS. RT 3.8.8 > > > --- > Jason Marshall > IT Manager > Kelman Data Management > -------- > RT Training Sessions (http://bestpractical.com/services/training.html) > * San Francisco, CA, USA October 18 & 19, 2011 > * Washington DC, USA October 31 & November 1, 2011 > * Melbourne VIC, Australia November 28 & 29, 2011 > * Barcelona, Spain November 28 & 29, 2011 -------- RT Training Sessions (http://bestpractical.com/services/training.html) * San Francisco, CA, USA October 18 & 19, 2011 * Washington DC, USA October 31 & November 1, 2011 * Melbourne VIC, Australia November 28 & 29, 2011 * Barcelona, Spain November 28 & 29, 2011
