[rt-users] Tickets for multiple groups

[Kenneth Crocker]

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 at bestpractical.com
> 
> 
> Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
> Buy a copy at http://rtbook.bestpractical.com
>