Request Tracker

From Biowiki
Jump to: navigation, search


We are using rt 3.6 for ticketing and bug/issue tracking.

Here is the URL:

Here are some pages about the rt software:

This RT system is intended to replace previous to-do lists on the wiki (Sys Admin Tasks, Xgram Wish List, JBrowse.WishList ...)

Add more tips and usage notes here.


Current queues:

  • Lab
  • Cluster
  • xrate-dev
  • Misc
  • Pipeline
  • TWiki

(to be broken out as tickets accumulate)

We can create an arbitrary number of public queues and individuals can create their own private queues as desired.

Admincc and Cc

For each queue, a list of Admincc and cc recipients can be configured. This list can contain users and/or groups.

From the RT wiki:

'''CCs''' on a Ticket are Users who are interested in the resolution of the ticket. 
A CC is like the Requestor in that they receive Correspondence but not Comments.

Users that have the Watch Right for a ticket can add or remove themselves as a CC.

An [[Admin CC]] gets both Correspondence and Comments. A CC might be a person outside 
the company whereas an [[Admin CC]] might be a member of Staff.

So if you set yourself as an Admincc, you do not also have to set yourself as a cc. This is not immediately apparent from the RT UI.

RT and Email

There are two halves to this:

Incoming mail for RT

Send mail to or Or in lieu of that, will work (and default to interacting with the 'Misc' queue). If you simply send a mail with a given Subject and Body, a new ticket will be created in QUEUENAME with the Subject header as the ticket name and the Body as the first ticket Comment.

If the Subject of the mail is [RTBIOWIKI #TICKETNUMBER] blahblahblah, a new comment will be added to the corresponding ticket with the contents of the mail body. This can be used to forward log or other output to RT, or attach files without using the web interface.

In general, mail from RT will have proper From and/or Reply-To addresses for interaction with a queue, and will include the proper Subject tag for easy response.

One can include Request Tracker Email Headers to specify different variables to RT.

Outgoing mail from RT

Right now more or less any action on a ticket will generate an email. Comments have a dropdown box to either generate an email to the requestor or not. Cc's can also be added. Whenever an email is generated, this is listed in the History for the ticket.

There is a global variable for RT, NotifyActor, which will suppress messages generated by an action by the recipient of the message (eg is the requestor for the ticket, and adds a reply or resolves the ticket). This is off by default, since the recipient already knows about the action, but for initial documentation and testing this has been turned on.

There is a whole set of Request Tracker Mail Templates that can be accessed via Configuration->Global->Templates, or - These can be used to generate a variety of informational mails when particular actions (Scrips) occur within RT. Right now, for example, the resolution email does not contain much information, so we may want to make some changes to this Template. See the Request Tracker Mail Templates page for some examples of how this can be used, and some of the variables/macros allowed.


Priorities go from 0 (lowest) upwards

Highest priority seems to be 2147483647, and something along the lines of 20 to 80 is common usage.

But you have an urgent request? Naturally! The following table's an attempt at a rough policy on what level is appropriate (this is for sysadmin-related stuff, hence top priority to IH and JPL):

Priority Interpretation Requester Example
>600 Immediate action required IH, JPL Fix tape backup system
200-600 Time-critical task IH, JPL Security upgrade
100-400 Urgent problem Anyone I can't do any work because...
0-100 General request Anyone Suggestion for cool new xrate feature

"Priority" vs "Final Priority"

From Jeremy's e-mail:

No, actually, this is not at all obvious, and I don't know whether it is documented or not. Probably not, unless one searches long and hard on the wiki and via google.

Here's what I think it does, and how I have actually used it in the past.

Generally the default is to set the priority/final to the same values, which means that is where they sit.

If you want something to become a BIG ISSUE in 60 days, you set the Priority to 20 and the final to, say, 80, with a final date 60 days in the future. Or 120 days in the future for things you want to get done 3 times a year. Then it will increment either every day or every other day, or whatever multiple works.

I have actually never just set the priority to 20 and the final to 50 without any date involved, to see what happens. What I think is supposed to happen is that it will increment by one per day until it reaches the final value, marching along nicely if no date is given.

But for whatever reason I've never used it like that. I'm trying a few out now. Usually I manually fiddle with priorities myself or let other people adjust them. Some places seem to use queues for all kinds of advancing priorities, or 'time bombs' that will page when they reach a particular priority, or will move automatically to a higher-tier queue, or whatever. The amount of stupidly complex things you can do with RT is pretty much unlimited.

Interwiki links

You can make a quick link from this wiki to a specific numbered ticket using the Inter Wiki syntax "Ticket:ID" where ID is the ticket number. For example: