RT:Request Tracker

This documentation describes what RT is and how to use it

How to use this document

This page is organised into two parts. First, there is a general section which explains RT as a system without providing any details of the local setup. The second section deals with any local customisations or configurations that may be of interest to local users.

I've tried to define any new words as I come across them. Further uses of the word should be linked back to the original definition. A definition looks like this:

Term Definition of term

What is RT?

Request Tracker tracks requests. Requests are entered into queues either by sending email to a special address or by using the web interface.

Alternatively, you could say that RT is a mechanism for managing and archiving email threads with a web interface.

RT is both of these. The former describes its use and the latter describes its implementation. There are other interfaces, via email and CLI, but this document focuses on the web interface

Queue A queue is a way of grouping requests. A queue has the following attributes:
  • A list of members who are authorised to manipulate requests in this queue.
  • One or more members who are designated administrators and can configure queue options
  • A mail alias to which new requests or feedback on existing requests can be sent.
  • Possibly a list of areas which divide the queue into smaller units
  • A set of configurable options accessible via the web admin interface with respect to setting up who gets mailed about what and who can raise requests in this queue.
  • A set of mail template files which can be configured to tailor messages sent by RT

When a request is received, it is assigned a unique identifier, a combination of a Site Identifier and a number. For example, [RequestTracker #127]. Usually, the requestor is notified when a request is submitted.

Requestor In RT, the Requestor is the person who raised the request. A requestor is usually represented as an email address. This is because the email address of the sender of a message to an RT queue alias is used to fill in the requestor field. When a request is raised using the web interface, the address is obtained from the 'email' field of the web user configuration.

Any change to a request is stored as a transaction.

Transaction A transaction is a stored change to a request. It may be a comment or a reply, or it may be a field change in the request headers or a state change. Each transaction is stored and the transaction history of a request may be viewed.

The other standard fields in a request are:

Serial Number The request's unique identifier. This is assigned on submission and cannot be changed.
Subject This is a text field containing (hopefully) a one line summary of the problem or request. This field does not have to be unique and can be changed at any time
Area Some queues are divided into areas. These areas simply provide a mechanism to narrow searches and to group requests into categories. Before defining an area, it would be wise to consider creating a new queue, particularly if requests in a certain area should be handled in any way different to requests in the main queue.
Queue The name of the queue.
Requestors See above
Owner The owner of a request is the person who is currently responsible for any action on the request. You could read this as "assigned to" without losing any meaning.
Status This field represents the state of a request. Currently the only states are:
State Meaning
open This request is unresolved and work is progressing.
stalled This request is unresolved but work is not progressing.
resolved This request has been resolved.
dead This request has been removed from the system. This state should only be used to kill duplicates as requests in this state lose all transaction information.
Last User Contact This field contains the date of the last time the requestor was contacted. Unless set explicitly, this field can be incorrect.
Priority The current priority of the request. Values range from 00 to 99
Due The request should be resolved by this date.
Last acted This is the date the last time the request was changed.
Created The date the request was submitted.

In addition to the requestor, the queue members are usually also notified via email.

Queue members Queue members are those people who have permission to manipulate requests in a queue

So, a request is submitted. The requestor and the queue members get mail, apparently from the queue mail alias containing the request. If anybody replies to the message, leaving the subject intact, the reply will be filed in RT as a comment on the request, and mailed out to the queue members, and so on and so on. Changes to status or other fields can be made via the web interface.

RT uses the subject line of a message to decide what to do with it. If the subject contains the identifier of a request that already exists, the message becomes a comment. If the subject line contains no identifier, a new request will be created. Thus you should be careful with the subject header when sending messages to the RT alias to avoid creating new requests where they are not needed.

So, once a request is created, what next? You will notice a couple of things about mail sent by RT. First of all, the From address is the mail alias for that queue (though the Real name field is likely to be set to the requestor). Thus, if you reply to the message, it is sent back to RT where the reply will be appended to the request and sent to the queue members and the requestor. You can also reply to or comment on a request using the web interface.

Secondly, the subject looks like this:

Subject: [RequestTracker #187] (at-review) Clean up code

The format of this line is:

Subject: [<Site ID> #<request number>] (<queue name>) <subject>

If you reply to an RT message without changing the subject, RT knows which request you are referring too. If you change the subject, RT won't know and will assume that you intend to create a new request. Of course, a preceding Re: is ignored.

There are four levels of access to any particular queue:

What can I do with a request?

There are many things that you can do with a request, the most common are commenting and replying. These actions have specific meanings in RT.

Comment For a given Queue, anyone with Manipulate privileges or higher may Comment on a Request. Commenting is the most common way to update a Request. It adds a Transaction and may or may not (depending on how the Queue is configured) automatically send mail to the Requestor or the queue members. It is intended to be used for "internal" correspondence that is not sent to the user. Comments would only be sent to the requestor at installations which have enabled "Notify User on Action" which is not recommended, because of the sheer volume of mail involved.
Reply Replying to a Request does much the same thing as Commenting on it does, but it also explicitly sends email to the Requestor, regardless of how the Queue is configured. RT will note the time of this communication in the Last User Contact field.

The most common way to comment or reply to a message is to use email. To comment, simply reply to an RT message or create a new message with the following string in the subject:

[RequestTracker #<request id>]

To reply, simply reply to the message and Cc: the requestor

The Web interface: Changing a request

While email is the easiest way to comment on or reply to a request, most other changes are easiest in the web interface.

Logging In

To log in, you need to (using your browser) go to the local RT URL. You will be presented with the login screen if:

otherwise you will be presented with the display queue. You need to enter your username and password (your RT password, not your account password) at the relevant prompts. If you are returned to those prompts, then something went wrong, otherwise you should get to the display queue. Note: you must have cookies turned on to log in.

The display queue and querying

When you first log in, you are presented with a list of all unresolved requests. If you can't easily find the request you want, scroll to the bottom of the RT page where you will find some selection boxes and a button marked "Update Queue filters". You can use these to query the database to narrow your search.

This is what you'll see if you successfully log in or you click the 'Display Queue' link in RT. A table is presented with various request fields and is filled in with all open bugs in queues where you have display access or better. Some notes about this page:

The request display and changing fields

When you click on a request id in the queue display you are presented with the request display. In the request display, the following are displayed:

To change a request field, simply click on one of the links at the top and bottom of the page or click on the fieldname in the request display. The following table shows the result of these actions.

Link/field Result
Comment This link puts you in a form where you can enter a comment, just as if you had replied to mail from RT about a particular request. You can Cc: or Bcc: the comment if you wish.
Reply This link puts you in a similar form to the comment one with two major differences:
  1. You can change the state of the request from the form.
  2. The reply is automatically sent to the requestor.
Take Taking a Request assigns it to the Taker. Their ID goes into the Owner field. You may only Take a Request if it is unowned -- if someone else already Owns the Request, you have to Steal it from them to gain Ownership.
Untake Untaking a Request removes your name from the Assigned field, making the Request un-Owned again. Useful in cases where you've Taken the wrong Request, or you've become overburdened, underinformed, fired, reassigned, amnesiac, promoted, or something else.
Steal Stealing a Request re-assigns an already Owned request to you, instead of to its current Owner. Useful in cases where the original Owner (as compared to you) has become overburdened, underinformed, fired, reassigned, amnesiac, promoted, or something else.
Give Assign a Request to someone else, and remove yourself from the Assigned field.
Last User Contact Tells RT that somehow, the person who made the original Request has been contacted. Automatically tagged when someone uses the Reply function, rather than simply Commenting. Useful when trying to measure the reponse-time back to users.

Example: While standing at the buffet, Charlie notices he's standing elbow to elbow with Biff, who sent in a Request that morning. Charlie tells Biff that he may wish to untoggle his caps lock key if he wants man pages to work for him. Biff walks away pleased, and after lunch, Charlie notes the interaction in the Request, including the fact that the Requestor was notified. Charlie's boss notices the fast turnaround time and rewards Charlie with a large nerf weapon and permission to use it.

Subject Change the subject of a request. Note that RT does not keep track of the former subject. If you would like it preserved, you are advised to enter a comment saying that you have changed the subject:

Example: Changed subject from "Can't log in during full moon" to "Werewolf infestation in machine room"

Queue This is how you move a request from one queue to another. Simply select the destination queue from the menu and click. You may move a request from any queue you can manipulate into any queue you can create requests in.
Area Assign a Request to a particular Area within a Queue.
Status You may change the Status of a Request to one of the four possible States: Open, Stalled, Resolved, and Dead.

EX: The Sphinx asked this riddle of a traveller: What is Open in the morning, Stalled in midday, Resolved by evening, and Dead by night? The traveller responded, "Either metaphorically, Man, or literally, a hyperactive Request." She was right, but the Sphinx ate her anyhow.

Requestor You may change the Requestor field if the Requestor or their email address changes.
Due Date You may change the Due Date to make it look like all of your requests are getting done right on time.
Priority You may change the current and/or Final Priority to reflect changes in the Request's importance in the grand scheme of things.
Serial number (merging) If a user opens a Request that turns out to be redundant, or which contains information more appropriate to continue an already open Request than to start one anew, you may merge all the entirety of one Request into another.
Last Action non-clickable
Created non-clickable

Creating a new request

To add a request, log in if you haven't already, then look for the button marked "Create request in queue". Once you have found it, select the queue that you would like to add a request to and hit the button (the default queue is the sam queue for system administration requests).

Fill in the form, making sure that you use an informative subject line and include all relevant information. Fields you should always check are:

Area - Some queues are divided into areas or subqueues

Priority - Each queue can define its own priority scheme

Owner - This is the person currently assigned to deal with this request

Date Due - When this request should be resolved.

Requestor - This should be your email address.

Updating an existing request

To update a request, either find it in the table and click on its Id number, or if you already know it's number, find the button "Display request #", type in the number of the request and hit the button.

Exit

Clicking on this button will log you out of RT and place you back at the Login screen.

Administration web interface

If you go to the admin URL, you can change your password or personal details by clicking on the "Modify your user account" button. Enter any new information then press the "Update user" button. You may need to log in first. If you have admin privileges for a queue, you can change that queue's parameters as well. If you have admin_rt privilege, you can change personal details for any user. You will only be shown those functions which you have permission to perform.

Modify Your RT Account

Hitting this button takes you to a form where you can enter the following details:

When you have set the fields you require, click on the "Update User" button at the bottom of the page.

Modify the user called

This is the same as modifying your own account except that you can modify anybody's details.

Create a User called

Again, this is the same as modifying your own account except that you must fill in a username as well.

Modify the Queue called

Hitting this button takes you to a form where you can enter the following details:

When you have finished setting the options you desire, hit the "Update Queue" button to set the options in the RT database. Use the "Delete Queue" button to delete a queue and the "Main Menu" button to cancel the operation.

Create a Queue called

This is the same as Modify the Queue called except that you need to specify the name of the new queue. In addition there is some necessary setup (mail aliases and template files) that can not at present be achieved using the web interface.

Local customisations

Important URLs