[rt-users] RT best practice

[Jorey Bump]

Tim Wilson wrote:

> Hi everyone,
> 
> Other than some final email configuration, my RT install is ready to go. I
> wonder if some of the RT gurus on the list would be willing to offer a
> suggestion or two about how to configure RT for my organization.
> 
> I work for a fairly large school district (about 9,000 students K-12). We
> have 10 different schools plus a district office where we have several
> district-wide tech support people and network managers. Each of our schools
> has at least one dedicated tech support person.
> 
> Most day to day tech support issues get handled by the tech support people
> in the schools. Occasionally they run into problems that need to be
> addressed by one of us at the district office. The district office staff
> work on network issues, servers, and the like.
> 
> I have questions like:
> 
> 1. Should I have lots of queues with each building having its own complete
> set, duplicating queues in other buildings, or should I have relatively few
> with the building techs managing their own tickets within the larger queues?

I'm no guru, but I'm supporting three different installations of RT3 in 
totally disparate environments. There's no doubt in my mind that the 
"less is more" approach provides the most value and flexibility with RT. 
  One enormous advantage of handling your tech support in one queue is 
that techs can help each other, even if they are from different schools. 
We all have different strengths, and allowing techs to see other tickets 
gives them an opportunity to share their knowledge. In fact, I see that 
as one of the principle strengths of RT.

> 2. A related question... Should I have lots of email address for our
> teachers to try to remember, or should we create a bare minimum and have our
> techs sort tickets as they come in?

Well, you seem to be aware of the problem already: Why place an extra 
burden on the end user? There's no question that support issues are best 
handled with a single address, like support at example.com, but if your 
categorization is efficient, other addresses can be useful. For example, 
it makes perfect sense to have a webmaster at example.com address and 
corresponding queue to handle issues related to your web site.

> 3. How could we use RT groups to better organizer our tickets?

Groups are for administering users, queues are for organizing tickets. 
Even if you have only one queue, it makes sense to create a group. You 
add users to the group, then assign the group rights, either globally or 
for each queue. This is a lot easier than setting up individual user 
rights for every queue. I repeat: a LOT easier.

For example, one model I've been using is to have an admin group and a 
staff group for each queue. The only real difference is that the admin 
group has the right to delete tickets. I can easily move members between 
groups to alter their rights.

> 4. Is it possible to create a queue that only one person could see and work
> on?

Yes, of course. But keep in mind that root sees all. If you can't trust 
the administrator, you should run your own instance of RT.