Re: [rt-users] Question about restricting queues
Am 17.06.2013 20:33, schrieb Chris Hall: I've got a bit of a weird problem, and wondered if anybody has a solution for it. We have several queues, and a few are grouped up by name. For example: Queue A tier 1 Queue A tier 2 Queue A tier 3 Queue B tier 1 Queue B tier 2 Queue B tier 3 The managers at the helpdesk are having a problem w/ ppl making a ticket in Queue A tier 1, and then when they escalate it, accidentally transferring it to Queue B tier 2 (instead of Queue A tier 2). They asked me if there was any way to group these queues up in such a way that, for example, if a ticket is made in any of the Queue A's they are locked in and can only be transferred between the Queue A's. I hope that makes sense. The problem is some of these queues are tied to different businesses, and if we send out an email due to a ticket queue transfer and it goes to the wrong company it looks bad on us. I know personal responsibility can go a long way to fixing this but besides that, is there any way to do what I described above w/ RT? As always ;-), there is an extension for this: RT-Extension-MoveRules https://github.com/ruz/RT-Extension-MoveRules As the extension isn't updated within the last years maybe it will not work with your RT version. If so just give some feedback to the list and maybe the developer have time to update the extension. Chris -- RT Training in Seattle, June 19-20: http://bestpractical.com/training
Re: [rt-users] Question about restricting queues
On Wed, Jun 19, 2013 at 3:18 PM, Christian Loos cl...@netcologne.de wrote: Am 17.06.2013 20:33, schrieb Chris Hall: I've got a bit of a weird problem, and wondered if anybody has a solution for it. We have several queues, and a few are grouped up by name. For example: Queue A tier 1 Queue A tier 2 Queue A tier 3 Queue B tier 1 Queue B tier 2 Queue B tier 3 The managers at the helpdesk are having a problem w/ ppl making a ticket in Queue A tier 1, and then when they escalate it, accidentally transferring it to Queue B tier 2 (instead of Queue A tier 2). They asked me if there was any way to group these queues up in such a way that, for example, if a ticket is made in any of the Queue A's they are locked in and can only be transferred between the Queue A's. I hope that makes sense. The problem is some of these queues are tied to different businesses, and if we send out an email due to a ticket queue transfer and it goes to the wrong company it looks bad on us. I know personal responsibility can go a long way to fixing this but besides that, is there any way to do what I described above w/ RT? As always ;-), there is an extension for this: RT-Extension-MoveRules https://github.com/ruz/RT-Extension-MoveRules As the extension isn't updated within the last years maybe it will not work with your RT version. If so just give some feedback to the list and maybe the developer have time to update the extension. I'm developer. Probably this summer I wouldn't have cycles to check it on my own. If it doesn't work then clean patches/pull requests are more than welcome or you can always book my time via sa...@bestpractical.com. Chris -- RT Training in Seattle, June 19-20: http://bestpractical.com/training -- Best regards, Ruslan.
Re: [rt-users] Question about restricting queues
Le 17/06/2013 20:33, Chris Hall a écrit :
They asked me if there was any way to group these queues up in such a
way that, for example, if a ticket is made in any of the Queue A's
they are locked in and can only be transferred between the Queue
A's.
Depending on your setup/organization, you could restrict the visible queues
(some people would have access to queues A tier 1/2/3, others to Queues B tier
1/2/3).
If this is not possible, you could force the correct queue or reject the
transfer from inside a scrip I guess, something like this (untested) :
Example to reject the transaction :
In condition :
my $TransObj = $self-TransactionObj;
if ($TransObj-Type eq Set and $transObj-Field eq Queue) {
return 0 if (substr($TransObj-OldValue,0,7) ne
substr($TransObj-NewValue,0,7); # 7 is length of Queue A
}
return 1;
--
RT Training in Seattle, June 19-20: http://bestpractical.com/training
Re: [rt-users] Question about restricting queues
On Mon, Jun 17, 2013 at 02:33:07PM -0400, Chris Hall wrote: I've got a bit of a weird problem, and wondered if anybody has a solution for it. We have several queues, and a few are grouped up by name. For example: Queue A tier 1 Queue A tier 2 Queue A tier 3 Queue B tier 1 Queue B tier 2 Queue B tier 3 The managers at the helpdesk are having a problem w/ ppl making a ticket in Queue A tier 1, and then when they escalate it, accidentally transferring it to Queue B tier 2 (instead of Queue A tier 2). They asked me if there was any way to group these queues up in such a way that, for example, if a ticket is made in any of the Queue A's they are locked in and can only be transferred between the Queue A's. As Jean-Christophe notes, the common solution is Don't let them have access to B but you may not be able to do that. Unfortunately, a Scrip runs too late to stop the email from going out with the other queue's email address. The best solution may be modifying SelectQueue (using a callback if available) to limit the set of Queues presented to non-admin users. -kevin pgpkwlNZZVYl9.pgp Description: PGP signature -- RT Training in Seattle, June 19-20: http://bestpractical.com/training
Re: [rt-users] Question about restricting queues
On 06/18/2013 11:08 AM, Kevin Falcone wrote: On Mon, Jun 17, 2013 at 02:33:07PM -0400, Chris Hall wrote: I've got a bit of a weird problem, and wondered if anybody has a solution for it. We have several queues, and a few are grouped up by name. For example: Queue A tier 1 Queue A tier 2 Queue A tier 3 Queue B tier 1 Queue B tier 2 Queue B tier 3 The managers at the helpdesk are having a problem w/ ppl making a ticket in Queue A tier 1, and then when they escalate it, accidentally transferring it to Queue B tier 2 (instead of Queue A tier 2). They asked me if there was any way to group these queues up in such a way that, for example, if a ticket is made in any of the Queue A's they are locked in and can only be transferred between the Queue A's. As Jean-Christophe notes, the common solution is Don't let them have access to B but you may not be able to do that. Unfortunately, a Scrip runs too late to stop the email from going out with the other queue's email address. The best solution may be modifying SelectQueue (using a callback if available) to limit the set of Queues presented to non-admin users. Another solution which may be acceptable is defining different lifecycles for each trio of queues. The lifecycles don't have to actually be different, just named differently. Then if you omit a mapping between the two lifecycles, RT will prevent tickets moving between them (by _anyone_). It's a bit of a misuse, but will work. -- RT Training in Seattle, June 19-20: http://bestpractical.com/training
[rt-users] Question about restricting queues
I've got a bit of a weird problem, and wondered if anybody has a solution for it. We have several queues, and a few are grouped up by name. For example: Queue A tier 1 Queue A tier 2 Queue A tier 3 Queue B tier 1 Queue B tier 2 Queue B tier 3 The managers at the helpdesk are having a problem w/ ppl making a ticket in Queue A tier 1, and then when they escalate it, accidentally transferring it to Queue B tier 2 (instead of Queue A tier 2). They asked me if there was any way to group these queues up in such a way that, for example, if a ticket is made in any of the Queue A's they are locked in and can only be transferred between the Queue A's. I hope that makes sense. The problem is some of these queues are tied to different businesses, and if we send out an email due to a ticket queue transfer and it goes to the wrong company it looks bad on us. I know personal responsibility can go a long way to fixing this but besides that, is there any way to do what I described above w/ RT? -- RT Training in Seattle, June 19-20: http://bestpractical.com/training
