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 (SysAdminTasks
Add more tips and usage notes here.
(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 AdminCC gets both Correspondence and Comments. A CC might be a person outside
the company whereas an AdminCC 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 QUEUENAME@rt.biowiki.org
Or in lieu of that, email@example.com
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 RequestTrackerEmailHeaders
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 firstname.lastname@example.org
is the requestor for the ticket, and email@example.com
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 RequestTrackerMailTemplates
that can be accessed via Configuration->Global->Templates, or https://rt.biowiki.org/rt/Admin/Global/Templates.html
- 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 RequestTrackerMailTemplates
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):
|| Immediate action required
|| IH, JPL
|| Fix tape backup system
|| Time-critical task
|| IH, JPL
|| Security upgrade
|| Urgent problem
|| I can't do any work because...
|| General request
|| 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
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.
You can make a quick link from this wiki to a specific numbered ticket using the InterWiki
"Ticket:ID" where ID is the ticket number.