This documentation describes what RT is and how to use it
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 |
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:
|
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:
|
||||||||||
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:
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.
What can I do with a request?
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
While email is the easiest way to comment on or reply to a request, most other changes are
easiest in the web interface.
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.
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:
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.
Logging In
The display queue and querying
The request display and changing fields
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:
|
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 |
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.
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.
Clicking on this button will log you out of RT and place you
back at the Login screen.
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.
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.
This is the same as modifying your
own account except that you can modify anybody's details.
Again, this is the same as modifying your own account except
that you must fill in a username as well.
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.
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.
Updating an existing request
Exit
Administration web interface
Modify Your RT Account
Modify the user called
Create a User called
Modify the Queue called
Create a Queue called
Local customisations
Important URLs