Tickets for multiple groups


#1

Hi Folks,
We’ve been using RT for some years, but now with a decision to
ditch Remedy and move all groups to RT, we’re getting quite a few
new queues. This has caused the situation to arise where some
tickets fall into the cracks between groups. A user might send
email to the addresses for the Unix team and the Security team,
because it’s a unix security issue, for instance. Because there’s
only one underlying email address and a procmail script that
picks a queue for it to go into based on email address, one of
those addresses ‘wins’. The falling-into-cracks happens when
staff sees both addresses on the ticket but don’t realize the
other team hasn’t seen it and don’t realize they have an action
item.

How do other organizations handle this? The case where it’s
in the wrong queue is easy: just transfer the ticket to the
right queue and the scrip notifies the new watchers. When
it really is something that both sets of watchers should watch,
then it gets tricky. We’ve thought of:

  1. Have the procmail script create duplicate tickets in each
    queue. All watchers get notified, but don’t see correspondence
    in the other queue. Putting ‘related’ links in the tickets only
    helps a small amount.

  2. Put the ticket in one main queue and a child ticket in the other
    queue to notify watchers there is something to watch. Then there’s
    a placeholder and a click-through link to the real ticket. There’s
    no notification of updates to the watchers of the other queue, though.

  3. Put in enough handshaking between the procmail script and an
    on-create scrip to add the watchers of the second queue to the
    ticket. All the right people get notified then, but someone who is
    working from the web UI don’t see it in the second queue. (Our
    "dispatch" people tend to work from the web UI, while solvers not
    on duty tend to rely on watcher email.)

  4. Go to a single queue, add a multi-valued custom field ‘area’ that
    contains the former queue names, can be used for searching and
    subsetting, and with some programming can maintain the right set of
    watchers on each ticket. This is a fair bit of programming to re-invent
    queue functionality.

None of these is ideal, though 3 perhaps comes closest. Has anyone
thought of a more inventive approach for supporting multiple teams who
generally have separate work queues but must sometimes collaborate on
solving tickets?

Best,
-Chuck Boeheim
Stanford Linear Accelerator Center


#2

Chuck,

We have over 100 technical support queues. Many of them part of the 

same overall support group, but a different software application. We
offer to the users of each application the email address for only the
queue they would send a request to for ‘that’ application. Some "groups"
have a central queue where requests for several software applications go
and there they are evaluated, approved, prioritized before being moved
to the specific queue that supports that specific software. We control
all that by using very few global privileges (just those that we want to
apply to roles, like requestors, regardless of queue) putting most of
the restrictions on the queue level and we allow NO privileges to
individual users (except 2 superusers, who act as System Admins). All
users are in specific groups and those groups are limited in access to
queues by the privileges at that queue level. Hope this helps.

Kenn
LBNLOn 6/17/2008 9:01 AM, Chuck Boeheim wrote:

Hi Folks,
We’ve been using RT for some years, but now with a decision to
ditch Remedy and move all groups to RT, we’re getting quite a few
new queues. This has caused the situation to arise where some
tickets fall into the cracks between groups. A user might send
email to the addresses for the Unix team and the Security team,
because it’s a unix security issue, for instance. Because there’s
only one underlying email address and a procmail script that
picks a queue for it to go into based on email address, one of
those addresses ‘wins’. The falling-into-cracks happens when
staff sees both addresses on the ticket but don’t realize the
other team hasn’t seen it and don’t realize they have an action
item.

How do other organizations handle this? The case where it’s
in the wrong queue is easy: just transfer the ticket to the
right queue and the scrip notifies the new watchers. When
it really is something that both sets of watchers should watch,
then it gets tricky. We’ve thought of:

  1. Have the procmail script create duplicate tickets in each
    queue. All watchers get notified, but don’t see correspondence
    in the other queue. Putting ‘related’ links in the tickets only
    helps a small amount.

  2. Put the ticket in one main queue and a child ticket in the other
    queue to notify watchers there is something to watch. Then there’s
    a placeholder and a click-through link to the real ticket. There’s
    no notification of updates to the watchers of the other queue, though.

  3. Put in enough handshaking between the procmail script and an
    on-create scrip to add the watchers of the second queue to the
    ticket. All the right people get notified then, but someone who is
    working from the web UI don’t see it in the second queue. (Our
    "dispatch" people tend to work from the web UI, while solvers not
    on duty tend to rely on watcher email.)

  4. Go to a single queue, add a multi-valued custom field ‘area’ that
    contains the former queue names, can be used for searching and
    subsetting, and with some programming can maintain the right set of
    watchers on each ticket. This is a fair bit of programming to re-invent
    queue functionality.

None of these is ideal, though 3 perhaps comes closest. Has anyone
thought of a more inventive approach for supporting multiple teams who
generally have separate work queues but must sometimes collaborate on
solving tickets?

Best,
-Chuck Boeheim
Stanford Linear Accelerator Center


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com


#3

Thanks for the response, Kenn, but I don’t think that describes
this particular problem. I’m concerned with the case where
you might like to have a ticket show up in two queues, and
updates be seen by the union of the watchers of those two
queues. For instance, we have queues for the windows team,
the unix team, and the security team. Most problems are within
one problem domain, but some tickets are unix security problems,
or unix-windows interoperability, er, opportunities. Each team
looks at the list of open tickets in their own queue, but it
would be nice if some tickets could show up in two queues.
-ChuckOn Jun 18, 2008, at 1:25 PM, Kenneth Crocker wrote:

Chuck,

We have over 100 technical support queues. Many of them part of the
same overall support group, but a different software application. We
offer to the users of each application the email address for only
the queue they would send a request to for ‘that’ application. Some
"groups" have a central queue where requests for several software
applications go and there they are evaluated, approved, prioritized
before being moved to the specific queue that supports that specific
software. We control all that by using very few global privileges
(just those that we want to apply to roles, like requestors,
regardless of queue) putting most of the restrictions on the queue
level and we allow NO privileges to individual users (except 2
superusers, who act as System Admins). All users are in specific
groups and those groups are limited in access to queues by the
privileges at that queue level. Hope this helps.

Kenn
LBNL

On 6/17/2008 9:01 AM, Chuck Boeheim wrote:

Hi Folks,
We’ve been using RT for some years, but now with a decision to
ditch Remedy and move all groups to RT, we’re getting quite a few
new queues. This has caused the situation to arise where some
tickets fall into the cracks between groups. A user might send
email to the addresses for the Unix team and the Security team,
because it’s a unix security issue, for instance. Because there’s
only one underlying email address and a procmail script that
picks a queue for it to go into based on email address, one of
those addresses ‘wins’. The falling-into-cracks happens when
staff sees both addresses on the ticket but don’t realize the
other team hasn’t seen it and don’t realize they have an action
item.
How do other organizations handle this? The case where it’s
in the wrong queue is easy: just transfer the ticket to the
right queue and the scrip notifies the new watchers. When
it really is something that both sets of watchers should watch,
then it gets tricky. We’ve thought of:

  1. Have the procmail script create duplicate tickets in each
    queue. All watchers get notified, but don’t see correspondence
    in the other queue. Putting ‘related’ links in the tickets only
    helps a small amount.
  2. Put the ticket in one main queue and a child ticket in the other
    queue to notify watchers there is something to watch. Then there’s
    a placeholder and a click-through link to the real ticket. There’s
    no notification of updates to the watchers of the other queue,
    though.
  3. Put in enough handshaking between the procmail script and an on-
    create scrip to add the watchers of the second queue to the
    ticket. All the right people get notified then, but someone who is
    working from the web UI don’t see it in the second queue. (Our
    "dispatch" people tend to work from the web UI, while solvers not
    on duty tend to rely on watcher email.)
  4. Go to a single queue, add a multi-valued custom field 'area’
    that contains the former queue names, can be used for searching and
    subsetting, and with some programming can maintain the right set of
    watchers on each ticket. This is a fair bit of programming to re-
    invent queue functionality.
    None of these is ideal, though 3 perhaps comes closest. Has anyone
    thought of a more inventive approach for supporting multiple teams
    who generally have separate work queues but must sometimes
    collaborate on solving tickets?
    Best,
    -Chuck Boeheim
    Stanford Linear Accelerator Center

http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com
Discover RT’s hidden secrets with RT Essentials from O’Reilly
Media. Buy a copy at http://rtbook.bestpractical.com

smime.p7s (2.4 KB)