Queues?

RT Users
1

Hello all,

I’ve just finished setting up RT2 and am most impressed. I’m not sure
how best to set up my queues though… I currently have a handful of
clients I provide support for and have set up a queue for a couple of
them Then I noticed in the documentation an example with ‘Accounts’,
‘NOC’, ‘Support’, and figured perhaps I’m on the wrong track? I can
fairly reliably determine the client name from the domain name of the
requestor, or better yet, the email address they sent it to (ie
support@client1.com, support@client2.com, which each forward to
different aliases on the RT machine running qmail), so perhaps using
queues for them is overkill? Also there would ideally only be a small
handful of open tickets on each client at any given time. Do people
supporting multiple clients/sites use different queues for each? If not,
what is used instead?

I’m starting to think my queues should look something like:

Support
Accounts
Access
Hosting
DomainNames

etc.

Some feedback from RT users would be great - I’d rather not have to go
back and fix this later.

Sam

2

Sam Johnston wrote:

Hello all,

I’ve just finished setting up RT2 and am most impressed. I’m not sure
how best to set up my queues though… I currently have a handful of
clients I provide support for and have set up a queue for a couple of
them Then I noticed in the documentation an example with ‘Accounts’,
‘NOC’, ‘Support’, and figured perhaps I’m on the wrong track? I can
fairly reliably determine the client name from the domain name of the
requestor, or better yet, the email address they sent it to (ie
support@client1.com, support@client2.com, which each forward to
different aliases on the RT machine running qmail), so perhaps using
queues for them is overkill? Also there would ideally only be a small
handful of open tickets on each client at any given time. Do people
supporting multiple clients/sites use different queues for each? If not,
what is used instead?

This is one of the great advantages of RT: Since most of the structural
elements of the system (queues, tickets, keywords, users) are pretty
generic, there is more than one way to do it™, perl fashion.

The most important thing is setting up a sound structure, which only
works if You know what You need. For me, Queues are the semantically
biggest barrier between two types of tickets, and it�s up to Your
suppoprt structure if it’s more important to divide tickets by client ot
by type of ticket (as You seem to aim).

There are some things that are not as generic or automatic as some
people sometimes wish they were, but when faced with a bill for
implementing, they most of the time get astoundingly quiet on that
matter (although I deem Jesse’s pricing reasonable enough for services
on an otherwise open source royalty free generic tool). But as a matter
of fact, everything that is really needed in a request tracker will
eventually find it’s way into RT.

H.

Harald Wagener | Systemadministrator
FCB/Wilkens GmbH | Tel.:+49-40-2881-1252
An der Alster 42 | Fax.:+49-40-2881-1263
20099 Hamburg | http://www.fcb-wilkens.com

3

Some feedback from RT users would be great - I’d rather not have to go
back and fix this later.

Use Keywords, and tag the requests with the appropriate keyword for the
client.

Your next possibly obscure problem please? :wink:

Regards,

                         Bruce Campbell                            RIPE
               Systems/Network Engineer                             NCC
             www.ripe.net - PGP562C8B1B                      Operations