5.3. Queues

You'll want to set up a queue for each new department or long-lived project that you track in RT. Like users and groups, queues never go away, so you don't want to create too many. Create a queue each time you have a set of tasks or requests that will be handled by a separate group of people who track their own special metadata or have different privacy requirements than your existing queues.

If you've been following along, the instructions for creating a queue are going to look rather familiar. Click Configuration, then Queues, and then New queue. Figure 5-3 shows the new queue page.

The Queue Name is the primary way that you'll see the queue in the web interface and also from the mail gateway and some scrips. While you can use any name you want, it's easiest to stick with names that don't contain apostrophes, slashes, and other characters that might need special escaping. The Reply Address and Comment Address fields determine what RT will stick in the return address of outgoing response and comment emails. If you leave them blank, they default to the systemwide settings in your configuration file. RT also lets you set a default initial priority for tickets in the queue, as well as a final priority that only kicks in if you use the RT escalation tool.^[*] If you fill in the Requests should be due in _ _ days field, RT will automatically assign a due date that many days in the future for your tickets.

^[*] Run perldoc /opt/rt3/bin/rt-crontool for more information about the escalation tool.

Don't forget to set up RT's incoming mail gateway for your new queues. See Chapter 2 for instructions on how to do that.

Figure 5-3. Create a new queue

5.3.1. Roles

Once you've created a new queue, you should set up the default Cc and AdminCc lists for it. From the queue overview page (Configuration > Queue ><your queue>), click Watchers. Figure 5-4 shows the queue watchers page.

You can search for users and groups to add to the queue's Cc and AdminCc lists. These people will be added implicitly to those roles for every ticket in the queue and may also be granted rights based on your queue access control configuration.

5.3.2. Access Control

You can grant per-queue rights to users or to groups. We generally recommend that you grant all rights to roles and groups, as it makes administration much easier. From the queue overview page (Configuration > Queue > <your queue>), click Group Rights. On this page, shown in Figure 5-5, you can grant rights to role groups such as Requestor, AdminCc, and Cc, as well as system-internal groups like Everyone and Privileged.

Figure 5-4. Queue watchers

Figure 5-5. Granting group rights to a queue

To allow arbitrary remote users to submit tickets into a given queue by email, grant the system-internal group Everyone the rights SeeQueue, CreateTicket, ReplyToTicket, and CommentOnTicket.

To make sure your staff can work with tickets, you should grant your staff group all the following additional rights: ShowTicket, ShowTicketComments, Watch, WatchAsAdminCc, OwnTicket, and ModifyTicket. If you've given your staff group an AdminCc role for the queue, you can grant only these rights to the AdminCc role group.

If you'll be opening up the self-service interface to your requestors, you'll also need to grant the Requestor role group the ShowTicket right.

5.3.3. Scrips

Out of the box, RT comes with a relatively straight-forward set of scrips. These scrips take care of making sure that Requestors get an autoresponse when they create a ticket and that everyone gets copies of relevant email and other ticket updates. You can add custom scrips either globally or per queue, but they aren't required for making RT work correctly. We'll go into more detail about scrips in Chapter 6.