Re: [rt-users] Ticket replies not going to another queue
Kevin Falcone ha scritto: On Fri, May 30, 2014 at 03:07:05PM +, Guadagnino Cristiano wrote: While we understand this use case (and in fact have developed code for users who needed to be able to email other RT queues from inside RT): Is this something you have developed under a paid contract or is it part of the standard RT? If so, I may have missed something. It is something we have delivered to customers and has not seen a public release. Before public release, it would require refactorings to make supporting it in future releases easier and there has not been sufficient clamor nor support for it. -kevin Oh, ok thank you. Please add my +1 to this. Bye Cris -- RT Training - Boston, September 9-10 http://bestpractical.com/training
[rt-users] Ticket replies not going to another queue
Hi all, RT usage is taking off lately here: we started with one division using it, and now there are four divisions using it and a fifth coming soon. We have been using just one RT instance, using groups and ACLs to separate the queues of one division from the others. Every division has its own email address that forwards to RT, and everything has been working very well till now. However, we have had a little nuisance that is slowly becoming bigger due to the increased number of users and requestors. The problem arises when one requestor (requestors often are completely unaware of the fact we are using RT internally) send a ticket to a division, and that division replies that the request should be made to another division. At this point, the requestor often takes the reply and forwards it to the other division, leaving it intact. Now, if the other division is using RT, the mail message from the requestor is again turned into a ticket and - due to the fact that it already contains a ticket number - it is appended to the old ticket thread instead of creating a new ticket in the other division's queues. Is anybody having this issue? How did you solve it? Ideally I think RT should append to the original ticket only if the receiving address is the same as the original ticket. Or at least, this is how it could work in our environment. Anybody foreseeing possible problems with this approach? Thank you in advance. Bye Cris -- RT Training - Boston, September 9-10 http://bestpractical.com/training
Re: [rt-users] Ticket replies not going to another queue
On Fri, May 30, 2014 at 12:56:17PM +, Guadagnino Cristiano wrote: Hi all, RT usage is taking off lately here: we started with one division using it, and now there are four divisions using it and a fifth coming soon. We have been using just one RT instance, using groups and ACLs to separate the queues of one division from the others. Every division has its own email address that forwards to RT, and everything has been working very well till now. However, we have had a little nuisance that is slowly becoming bigger due to the increased number of users and requestors. The problem arises when one requestor (requestors often are completely unaware of the fact we are using RT internally) send a ticket to a division, and that division replies that the request should be made to another division. At this point, the requestor often takes the reply and forwards it to the other division, leaving it intact. Now, if the other division is using RT, the mail message from the requestor is again turned into a ticket and - due to the fact that it already contains a ticket number - it is appended to the old ticket thread instead of creating a new ticket in the other division's queues. Is anybody having this issue? How did you solve it? Ideally I think RT should append to the original ticket only if the receiving address is the same as the original ticket. Or at least, this is how it could work in our environment. Anybody foreseeing possible problems with this approach? Thank you in advance. Bye Cris Hi Cris, We a more general Helpdesk as one of the areas using RT and they have the rights to put a ticket in any of the other areas' submission queues. Then if something is mis-routed, we just drop it in the Helpdesk submission queue for re-routing. Regards, Ken -- RT Training - Boston, September 9-10 http://bestpractical.com/training
Re: [rt-users] Ticket replies not going to another queue
On Fri, May 30, 2014 at 12:56:17PM +, Guadagnino Cristiano wrote: Hi all, RT usage is taking off lately here: we started with one division using it, and now there are four divisions using it and a fifth coming soon. We have been using just one RT instance, using groups and ACLs to separate the queues of one division from the others. Every division has its own email address that forwards to RT, and everything has been working very well till now. However, we have had a little nuisance that is slowly becoming bigger due to the increased number of users and requestors. The problem arises when one requestor (requestors often are completely unaware of the fact we are using RT internally) send a ticket to a division, and that division replies that the request should be made to another division. At this point, the requestor often takes the reply and forwards it to the other division, leaving it intact. Now, if the other division is using RT, the mail message from the requestor is again turned into a ticket and - due to the fact that it already contains a ticket number - it is appended to the old ticket thread instead of creating a new ticket in the other division's queues. Is anybody having this issue? How did you solve it? Ideally I think RT should append to the original ticket only if the receiving address is the same as the original ticket. Or at least, this is how it could work in our environment. Anybody foreseeing possible problems with this approach? Thank you in advance. Bye Cris Hi Cris, We a more general Helpdesk as one of the areas using RT and they have the rights to put a ticket in any of the other areas' submission queues. Then if something is mis-routed, we just drop it in the Helpdesk submission queue for re-routing. Regards, Ken Ken, thank you for your reply. This is what we do if it is immediately apparent to us that the request should be routed to another division. Probably my example was a bit too simplistic, however the fact is that sometimes the requestor feels the urge to reissue a rejected request to a different division. In that case we're out of luck, as we see the ticket re-opening the old thread, instead of opening a new ticket in another queue. Any other suggestions? Bye Cris -- RT Training - Boston, September 9-10 http://bestpractical.com/training
Re: [rt-users] Ticket replies not going to another queue
On Fri, May 30, 2014 at 12:56:17PM +, Guadagnino Cristiano wrote: The problem arises when one requestor (requestors often are completely unaware of the fact we are using RT internally) send a ticket to a division, and that division replies that the request should be made to another division. At this point, the requestor often takes the reply and forwards it to the other division, leaving it intact. Now, if the other division is using RT, the mail message from the requestor is again turned into a ticket and - due to the fact that it already contains a ticket number - it is appended to the old ticket thread instead of creating a new ticket in the other division's queues. Is anybody having this issue? How did you solve it? While we understand this use case (and in fact have developed code for users who needed to be able to email other RT queues from inside RT): Ideally I think RT should append to the original ticket only if the receiving address is the same as the original ticket. Or at least, this is how it could work in our environment. Anybody foreseeing possible problems with this approach? This workflow will never become the default RT workflow. Too many people (including us) rely on email finding their way to an RT ticket regardless of whether they've moved to a separate escalation queue or just to the 'correct' queue. Also consider the many many people who have 5+ email addresses all feed into one queue. Assuming usage of a modern RT, the following extension forces creation of new tickets when a reply comes in to a resolved ticket. You could either use it as is, or modify it to check To: (and Cc:) vs Queue's correspond address and then trigger the new ticket creation. https://metacpan.org/release/RT-Extension-RepliesToResolved -kevin pgpPy072m7JLo.pgp Description: PGP signature -- RT Training - Boston, September 9-10 http://bestpractical.com/training
Re: [rt-users] Ticket replies not going to another queue
Kevin Falcone ha scritto: On Fri, May 30, 2014 at 12:56:17PM +, Guadagnino Cristiano wrote: The problem arises when one requestor (requestors often are completely unaware of the fact we are using RT internally) send a ticket to a division, and that division replies that the request should be made to another division. At this point, the requestor often takes the reply and forwards it to the other division, leaving it intact. Now, if the other division is using RT, the mail message from the requestor is again turned into a ticket and - due to the fact that it already contains a ticket number - it is appended to the old ticket thread instead of creating a new ticket in the other division's queues. Is anybody having this issue? How did you solve it? While we understand this use case (and in fact have developed code for users who needed to be able to email other RT queues from inside RT): Kevin, I am curious about this. Is this something you have developed under a paid contract or is it part of the standard RT? If so, I may have missed something. Ideally I think RT should append to the original ticket only if the receiving address is the same as the original ticket. Or at least, this is how it could work in our environment. Anybody foreseeing possible problems with this approach? This workflow will never become the default RT workflow. Too many people (including us) rely on email finding their way to an RT ticket regardless of whether they've moved to a separate escalation queue or just to the 'correct' queue. Also consider the many many people who have 5+ email addresses all feed into one queue. Assuming usage of a modern RT, the following extension forces creation of new tickets when a reply comes in to a resolved ticket. You could either use it as is, or modify it to check To: (and Cc:) vs Queue's correspond address and then trigger the new ticket creation. https://metacpan.org/release/RT-Extension-RepliesToResolved -kevin Thank you Kevin, I think I'll be perusing this extension. BTW, we're using RT 4.2.3. Bye Cris -- RT Training - Boston, September 9-10 http://bestpractical.com/training
Re: [rt-users] Ticket replies not going to another queue
On Fri, May 30, 2014 at 03:07:05PM +, Guadagnino Cristiano wrote: While we understand this use case (and in fact have developed code for users who needed to be able to email other RT queues from inside RT): Is this something you have developed under a paid contract or is it part of the standard RT? If so, I may have missed something. It is something we have delivered to customers and has not seen a public release. Before public release, it would require refactorings to make supporting it in future releases easier and there has not been sufficient clamor nor support for it. -kevin pgpZII5rvGKim.pgp Description: PGP signature -- RT Training - Boston, September 9-10 http://bestpractical.com/training
