Request Tracker User Guide

Yüklə 129,39 Kb.
ölçüsü129,39 Kb.
  1   2   3   4   5   6   7

Request Tracker

User Guide

Institutional Systems (IS) Department

Information Technology (IT) Division

Lawrence Berkeley National Laboratory

January 2008

Table of Contents


  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

  1. Email Interface 48

  2. Support 50

Chapter 1:


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.


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:


The ticket has just been created and hasn't been touched yet.


The ticket is being worked on.


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.


Hooray! Work on the ticket has been completed.


The ticket is not going to be resolved, for whatever reason, but needs to be recorded in the system.


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:



Something is very broken or someone can’t do their job. No workaround.



Something is partly broken or someone can’t do part of their job. No workaround.



Lots of annoyance. There is a (hopefully temporary) workaround.



Some annoyance. There is a workaround.



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:


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.


The person or persons who asked for something to get done. Not necessarily thre same as the ticket creator.


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.


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.


An overall, general ticket.


A subproject of a parent ticket.


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.

Yüklə 129,39 Kb.

Dostları ilə paylaş:
  1   2   3   4   5   6   7

Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur © 2023
rəhbərliyinə müraciət

    Ana səhifə