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?

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;

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

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.

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

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

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
GitHub - ruz/RT-Extension-MoveRules: control movements of tickets

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 sales@bestpractical.com.

Chris


RT Training in Seattle, June 19-20: http://bestpractical.com/training

Best regards, Ruslan.