Request Tracker User Guide

Request Tracker

User Guide

Institutional Systems (IS) Department

Information Technology (IT) Division

Lawrence Berkeley National Laboratory

January 2008

Table of Contents

Chapters

1. 
   Introduction 1
   
2. 
   Administration 5
   
3. 
   Logging In 7
   
4. 
   Home page 8
   
5. 
   Tickets Interface 14
   
6. 
   Common Tasks 26
   

Searching and Reporting 27

Create a New Ticket 40

Replying and Commenting 42

Updating Multiple Tickets 44

Resolving a Ticket 47

7. 
   Email Interface 48
   
8. 
   Support 50
   

Chapter 1:

Introduction

Welcome to Request Tracker (RT), a ticketing or request tracking system. This introductory chapter will explain the term ticketing and give an overview of concepts associated with the RT system. If you're already familiar with RT, you can skip ahead to another chapter.

About Ticketing

Ticketing is a way for projects and groups to keep track of their to-do lists, who is working on which ticket/task, which tickets are dependant on the completion of some other ticket/task, what's already been done, and when tasks were completed. You may also hear the phrase "trouble ticketing,” though there does not have to be a problem for ticketing to be useful.

Ticketing can make life easier for IS projects and groups -- basically anyone who needs to keep track of a list of tasks and it can be used for a variety of tasks, like fixing software bugs or tracking assignments for a software upgrade.

About RT

RT is an open-source ticketing system, so it didn’t cost anything to buy and we don’t have to renew licenses every year. However, this does not mean it is completely “free;” we must still maintain and administer it. This also means that there is little to no technical support or documentation passed along with the product. However, RT is a very robust, popular application and has a strong user community, so we do not expect this to be an issue. We will provide our own documentation and technical support, as needed.

Concepts

There are some words and phrases you should understand in the context of RT before you begin. Additional definitions can be found in a separate document, Request Tracker Glossary(select “SUPPORT”>Documentation on your RT Home Page.

A ticket is the central object in RT, the task that needs to get done. Tickets have metadata attached to them such as queue, requestor, owner, status, and comments.
A queue in RT is the way it collects/stores tickets into a central administrative function/organization; each queue is it’s own domain. 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 GL queue, but only the right to see tickets in the BAR queue.
A requestor in RT is the person with the initial request; not necessarily the person creating the ticket. The administrator of certain queue’s may not want just anyone creating tickets and will create all tickets, specifying who the requestor actually is.
An owner in RT is the person responsible to do the work entailed by the ticket/request; assigned either by the queue manager or (if allowed) taking ownership of the ticket individually.
The status dropdown 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 being worked on.
Stalled	Due to circumstances beyond your control, or because the QA results were not approved, 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.
Rejected	The ticket is not going to be resolved, for whatever reason, but needs to be recorded in the system.
Deleted	The ticket never should have been in the system. Deleted tickets are gone for good; they cannot be retrieved.

Ticket updates can take one of two forms. A reply is a public in response to an E_mail from the ticket. A comment is a note which is not related to E_mail. This is useful primarily for development staff communication, such as documenting technical information regarding the task or problems working on the task. The owner or manager may make modifications other ticket information as well (descriptions, dates, custom fields, etc.).

Ticket history is what it sounds like: everything that's happened to a ticket. Facets of ticket history include when the ticket was created, any change in information, the UserID of the person that made the change, any E_mail notifications sent out, and any comments about it or replies to it. Like real history, ticket history cannot be changed, so be aware that any comments you make about a ticket are permanent.
Priority, how important a ticket is, is represented as a numerical scale. By setting a final priority, you can make a ticket's priority increase or decrease as its due date draws closer (a special CRON job would need to be created for said promotion). In IS the priority is set from 5 to 1 with 1 being the highest priority.
Following is a reasonable description of the levels of priorities:

1	Fatal	Something is very broken or someone can’t do their job. No workaround.
2	Critical	Something is partly broken or someone can’t do part of their job. No workaround.
3	High	Lots of annoyance. There is a (hopefully temporary) workaround.
4	Medium	Some annoyance. There is a workaround.
5	Low	Minor annoyance or backburner task. There is a workaround.

Each queue may come up with their own description of what each priority means, however, 1 must be the highest priority, 5 the lowest and the remaining between those two.

There are two types of watchers. There is the Queue Watcher (CC role for Queue - someone who is interested in keeping track of the progress and/or communication of all tickets in a queue) and a ticket watcher (someone who is interested in keeping track of the progress and/or communication of a single ticket). Queue Watchers are selected by the Queue Administrator and given role rights to the queue. A Ticket Watcher is filed under "People" when you're looking at a ticket. There are several types, or roles, of people related to the ticket:

Owner	The person responsible for the ticket and its resolution. A ticket can have only one owner. Usually, only the owner and Queue Manager can modify the information on a ticket.
Requestor	The person or persons who asked for something to get done. Not necessarily thre same as the ticket creator.
CC:	Someone who should get copies of any notifications that go to “other”. This might be the requestor's boss, another user, etc. This person will see the email but will not necessarily have the right to log into RT or reply to the E_mail.
AdminCC:	A user who needs to get copies of any notifications that go to “AdminCc”.

Links, or relationships, in RT can be ticket-to-ticket, but can also be in the form of reminders (pseudo tickets) or relationships to external items like URLs. 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.
Depended on by	Another ticket can't be resolved unless this ticket is resolved. The converse is depends on.
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.
Referred to by	Another ticket refers to this ticket. The converse is refers to.
Parent	An overall, general ticket.
Child	A subproject of a parent ticket.
Reminders	A pseudo ticket with a relationship to a real ticket. These must be resolved just like real tickets in order to go away. They are NOT resolved automatically when the real ticket is resolved.

Custom Fields are database fields that can be created according to the needs of the queue. Queue Administrators may choose to apply an existing custom field to their queues to collect additional information. For example, I may decide that I want to record my customer’s “need by” date for requests, so I will apply an existing custom field called Customer Need-By Date to my queue. If such a Custom Field does not exist, I can ask (send a request to TSG-RT, including desired values) for the RT System Administrator to create one for me.

Notification Scrips are custom actions that are automatically triggered in response to specific conditions. For example, RT will email the requestor when a ticket is resolved. Customized scrips can be coded to trigger an action on an individual queue basis as well.
Now that you're clear on the concepts, you're ready to start using RT.