Cc:'s and replies driving me bonkers!

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

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.

MikeOn Oct 3, 2011, at 7:21 PM, Jason Marshall jasonm@kelman.com 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