Text only	University | Computing Services | Search | News | A-Z Index | Contact Us
	Computing Services
Problem? Check the FAQ

[How To | Searching | Admin]

RT

General Concepts

• RequestTracker (RT) deals with requests (tickets).
• Requests or tickets are input via email or via a web interface. People who submit requests are called requestors.
• Every ticket is displayed as a series of transactions which show the history of the ticket. Transactions can be additional messages, changes in priority/status etc.
• Requests or tickets live in queues. A queue provides a loose grouping of both what the ticket is about and who is likely to respond to it e.g. support queue, listmaster queue, resnet queue etc.
• Tickets can be assigned, taken, bounced between queues, merged or acted upon in many other ways. Tickets can have the following status:
  • New: The ticket has never been viewed or acted upon.
  • Open: The ticket has been viewed, and is being dealt with.
  • Stalled: The ticket has been put on hold as it cannot presently be resolved. If there is any further correspondence, the ticket will automatically be reopened.
  • Resolved: The ticket has been dealt with, and is no longer an issue.
  • Rejected: This indicates that the ticket was rejected: Usually tickets are only rejected in the case of inappropriate requests.
  • Deleted: This indicates that the ticket was deleted. Usually tickets are only deleted in the case of duplicate requests or spam email.
• Every queue has real people associated with it. The people either do the work, want the work to be done or lurk to see if the work is being done. All these people are called queue watchers. Watchers have the following roles:
  • Requestor: The person who has asked for help or the work to be done.
  • Cc/AdminCc: Watchers of the queue. Members of a team who have the ability to respond to the ticket
  • Owner: The person who has taken ownership of the ticket. Usually a member of the Cc/AdminCc.
• Each queue has email addresses associated with it - by default:
  • correspondence email address - the address of the queue itself - eg support@rt.bath.ac.uk
  • comment email address - the private address for the queue - eg support-comment@rt.bath.ac.uk
• Correspondence is something that is sent by one of the RT watchers to the requestor.
• Comments are normally set up to be internal to RT watchers, and never sent to the requestor.
• Most queues have actions associated with them. These are called scrips. Scrips are a way of telling RT to trigger certain actions based something happening. EG - when somebody submits a request to a queue, email all the watchers with the content of that request.
• RT supports web and email interfaces.

Procedural Overview

On the simplest level, RT tracks requests - tickets - and correspondence about them. It can do this via email (in fact email is one of its primary interfaces). Consider a support request to an organisation running RT:-

Requestor: My e-mail isn't working.

BUCS: Have you looked at the FAQ?
Can you be more specific about what isn't working.

Requestor: When I hit send in my mailer, it says
"Cannot connect to server"

BUCS: Please make sure you have your SMTP server configured as documented ...

Requestor: Thanks! That did it!

This exchange can all happen via email (it can also happen via a web interface). The original request can be submitted via email and the queue watchers can simply reply to the email to resolve the tickets. Once the original email has been submitted the call is injected into the RT system and allocated a ticket number. Every transaction associated with that ticked is now recorded in a permanent ticket history. From now on people don't interact directly with each other - they interact with the RT system and it decides what to do.

Whether the requestor receives acknowledgement of the call is queue configurable. Whether all the queue watchers receive updates on the ticket history via email is queue configurable. Queues are very configurable.

At another level each watcher may want to know the specifics of what the previous watcher informed the requestor, and their response to that. Others may also want to know who is handling a particular ticket, how long it's been open, how many total tickets are open, what category your ticket falls into ("e-mail problems"), etc. The web interface addresses these issues.

RT isn't only for help-desk situations. The same system can be used to track bugs in software, outstanding action items or any other issue. In this area, RT overlaps with programs such as Bugzilla and Gnats. In fact, RT's being used by the Perl 6 developers to track what they need to work on.

Interacting with RT via email

In short; simply reply to the email, the requestor will receive the reply and the ticket is resolved. Job done - move onto the next ticket.

If you are a watcher of a queue you can be setup to receive email for all requests sent to that queue. Depending upon the queue requests may be accepted directly from email or via the problem submission form. Watchers are usually set to receive email under the following circumstances (although this is configurable at a queue level):

• When a ticket is raised
• If a ticket is commented on - all other watcher receive the comment
• If a ticket is corresponded to - all other watchers receive the email (as does the requestor).
• When a ticket is taken - all other watchers are notified via email.

Appropriate sieve scripts can be written to manage email from the RT system and automatically filter into subfolders.

A request emailed to a queue watcher from RT will always have a ticket number in the subject line. Replying to this email (keeping the subject line intact) will send email back to the requestor and resolve the ticket. Other watchers of the queue will also receive a copy of the email for two reasons:

1. So they don't waste time solving the ticket when its already been done
2. So they know what the person who did solve the ticket actually did

What if you want to seek advice from your co-watchers before resolving a ticket and replying to the original requestor? RT can handle this - simply modify the reply address by inserting a -comment into the address to be replied to. So for example a ticket in the support queue will have a default reply-to address of support@rt.bath.ac.uk. Changing this to support-comment@rt.bath.ac.uk after hitting reply and before sending the email will not send this back to the original requestor. This email will only be send to the other watchers of the queue for internal discussion. RT will record the comment in the ticket history for future reference.

Email addresses for RT transactions

The full set of email address handled by the RT system are as follows:

• <queue>@rt.bath.ac.uk - the queue itself, generally used (if allowed) to submit calls from a requestor.
• <queue>-comment@rt.bath.ac.uk - comments to the ticket - these comments not sent to requestors, only to other queue watchers.
• <queue>-take@rt.bath.ac.uk - take the ticket.
• <queue>-open@rt.bath.ac.uk - open the ticket.
• <queue>-stall[ed]@rt.bath.ac.uk - stall the ticket.
• <queue>-resolve[d]@rt.bath.ac.uk - silently resolve the ticket (useful for 'thank you' replies).
• <queue>-reject[ed]@rt.bath.ac.uk - reject the ticket.
• <queue>-delete[d]@rt.bath.ac.uk - delete the ticket - use this to kill any spam that gets in.

Accessing RT via the Web

Point your browser to: http://rt.bath.ac.uk. From on campus you can just go to rt.From off campus you have to connect securely. Connect to https://rt.bath.ac.uk

In all cases login using your usual username and password. Initial screen is presented which will display the queues you have access to and any tickets you may own or have requested.

Browse queues via the Quick Search menu on the right. If you know a ticket number access it directly via the Search box in the top right hand corner. Keyword searches in this search box are restricted to new or open tickets currently on the system. More detailed searches can be performed via the main search box

Left hand navigation caters for getting home and ticket manipulation and management. Ticket menu will expand when tickets are opened and show the main ticket menu options of:

#7329 -> The main default ticket interface menu

• Display -> This screen
• History -> Remove ticket meta data - just show the history
• Basics -> Change ticket status, priorities and queues
• Dates -> Modify dates for the ticket.
• People -> Change owner, requestor, add and remove people from ticket tracking and monitoring
• Links -> Manages ticket relationships - merges, dependencies, referrals etc.
• Jumbo -> Concatenation of Basics, Dates, People and Links management screens

Tickets can be raised via the web interface although in reality it may be easier to abstract this to other forms for real customers (ie problem submission form) or simply allow people to email problems and queries in. It depends on the queue in question, the potential customer base and the reliability of the requestor in raising well structured calls.

More detailed info on driving the web interface:

• How to
• Searching
• Admin (for administrators)