Learning RT from scratch

RT is a self-proclaimed hairy beast. The documentation doesn't provide a concise introduction to the concepts, so here is my attempt at providing the most concise, but all-encompassing description of RT. It's pretty directly ripped from the RT wiki, with some fluff cut out.

The wiki home page

it's big, and learning how to set it up can take some time.

please plan to spend some quality time with the UserManual before you try to go live; RT is big and hairy, and you probably can't get your head around all of it in one sitting.

manual introduction

A Ticket is the central object in RT, the thing that needs to get done. Tickets have metadata attached to them such as an owner, status, and queue - we'll get to all that in a minute.

A Queue is the central administrative domain of RT; it keeps things organized. As the name implies, it's a line of tickets waiting to be worked on, but it's also, to some extent, the ticket's category. For instance, you might have the right to create, delete, and comment on tickets in the Foo queue, but only the right to comment on tickets in the Bar queue.

A ticket's history is what it sounds like: everything that's happened to a ticket. Facets of ticket history could include when the ticket was created, how it has changed, and any comments about it or replies to it. Like real history, ticket history cannot be changed (at least not without messing up the space-time continuum), so be aware that any comments you make about a ticket are permanent.

Ticket updates can take one of two forms. A reply is a public remark that a requestor can see. A comment is a private note for staff not visible to the requestor. This is useful when you want to be tactful but still convey important information, like, "This requestor is an investor, so be nice" or "This user's request mentioned his 'PC' but he really has a Mac."

Priority, how important a ticket is, is represented as numerical scale from 0-99, with 99 being the highest priority. ManualAdministration contains a useful model for setting organizational policy for priority.

The status drop-down menu offers several choices for classifying each ticket. Here's what they mean:

• NEW: the ticket has just been created and hasn't been touched yet.
• OPEN: the ticket is getting worked on
• STALLED: due to circumstances beyond your control (waiting for the requestor to respond, waiting for the owner to return from Sri Lanka), the ticket isn't getting worked on right now. It will open again when someone adds a comment or reply.
• RESOLVED: hooray! Work on the ticket has been completed and is out of everyone's hair.
• REJECTED: the ticket is not the staff's problem and is not going to be resolved, but is, for some reason, worth recording in the system. For instance, if an employee asks approval for something ridiculous, you can reject the ticket, but it will stay in the database as evidence that the employee makes silly requests.
• DELETED: the ticket never should have been in the system (maybe it was spam, a list of passwords, etc) -- and is now being zapped for good.

A watcher is someone who is interested in a ticket. You'll find these filed under "People" when you're looking at a ticket. A watcher of a ticket normally gets email-copies of all the replies to the ticket. The watchers who are staff-members get copies of the comments too. There are several types, or roles, of watchers:

• OWNER: the person responsible for the ticket and its resolution. Each ticket can have only one owner. As a ticket it worked on, it may be passed from one owner to another.
• REQUESTOR: the person or people who asked for something to get done; the ticket's reason for being. The Requestor normally gets copies of all replies to the ticket, but no comments.
• CC: someone (or someones) who should get copies of any replies that go to the requestor. This might be the requestor's boss, sales rep, etc. This person will see the emails but doesn't necessarily have the right to work on the ticket.
• ADMINCC: a Cc or Ccs that also gets copies of comments and generally are allowed to work on the ticket.

You can also, as you work on a ticket, define its relationship to something. Relationships in RT can be ticket-to-ticket, but can also link tickets to external items like URLs or FedEx shipping numbers. For the sake of simplicity, we'll refer only to tickets in the following explanation of relationship types:

• DEPENDS ON: the ticket can't be resolved unless another ticket is also resolved. The converse is depended on by.
• REFERS TO: the ticket doesn't need the other ticket, but it would sure be useful for you to look at it. The converse is referred to by.
• PARENT: a big, general ticket ("Move house.")
• CHILD: a subproject of a parent ("Hire movers." "Pack." "Eat pizza.")

CustomFields are, yes, database fields that your organization can make up according to its needs. For details, see the Custom Fields section in ManualAdministration. An example custom field might be Resolution: FIXED, WORKSFORME, WONTFIX, UPSTREAM, etc, etc... (If you think that example was stolen from Bugzilla, you have much to go on :-)

Scrips are custom notifications that will automatically take Action X in response to Condition Y. You could have RT notify the Requestor when a ticket is resolved, for instance, or have RT page you when your boss submits a request. RT comes with many standard scrips, and you can define your own. For details, see the Scrips section in ManualAdministration. And no, we didn't misspell "scripts." We made up a new word. Try it, it's fun.