[rt-users] Tickets for multiple groups

[Chuck Boeheim]

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