RT Essentials | O'Reilly Media

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

If your organization is anything like any of ours, there's always a lot of stuff to do. Vendors need to get paid. Customers need to get invoiced. Staff need to do work for customers. Sales inquiries need to be answered. Bugs in hard- or software need to be fixed, and everyone needs to know that they have been fixed. Somebody needs to take out the garbage. And at the end of the day, you've got to know who wanted what, who did it, when it got done, and most importantly what remains undone.

That's where a ticketing system comes in.

The convention is to call each request or piece of work a Ticket. When a new thing comes into the system, we give it a virtual slip of paper with a number, much like the ticket for checking your coat at the coat room or leaving your car in valet parking. This is the ticket we track.

Before we get into typical applications, let's dissect a generic ticketing system into its component parts, by building a list of the things a typical ticketing system will do. You can use this list to decide whether or not you need a ticketing system.

These are the bones of a true ticketing system:

Register an event or a ticket
Assign an owner, or person responsible, to the ticket
Assign additional interested parties to the ticket
Track changes to the ticket
Inform interested parties of these changes
Launch activity based on ticket status and/or priority
Report on status of one or more ticket(s)—an overview
Finish with, or close, the ticket

Note the list doesn't include a "Delete this Ticket" mechanism, even when it is finished, or closed. This is because it is essential for any professional ticketing solution to show the status of a Thing once it's entered into the system and the entire history of how it is handled. You should be able to close a Thing, but not remove knowledge of it, or what happened to it, from the system. On the other hand, it is possible and sometimes even desirable to remove erroneous entries from the system—such as duplicates or plain wrong entries. Deletion may be primarily a manual process, so that people will use it rarely. The prime intention here is to maintain a history of events and the current status, and never to lose it.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The convention is to call each request or piece of work a Ticket. When a new thing comes into the system, we give it a virtual slip of paper with a number, much like the ticket for checking your coat at the coat room or leaving your car in valet parking. This is the ticket we track.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Before we get into typical applications, let's dissect a generic ticketing system into its component parts, by building a list of the things a typical ticketing system will do. You can use this list to decide whether or not you need a ticketing system.

These are the bones of a true ticketing system:

Register an event or a ticket
Assign an owner, or person responsible, to the ticket
Assign additional interested parties to the ticket
Track changes to the ticket
Inform interested parties of these changes
Launch activity based on ticket status and/or priority
Report on status of one or more ticket(s)—an overview
Finish with, or close, the ticket

Note the list doesn't include a "Delete this Ticket" mechanism, even when it is finished, or closed. This is because it is essential for any professional ticketing solution to show the status of a Thing once it's entered into the system and the entire history of how it is handled. You should be able to close a Thing, but not remove knowledge of it, or what happened to it, from the system. On the other hand, it is possible and sometimes even desirable to remove erroneous entries from the system—such as duplicates or plain wrong entries. Deletion may be primarily a manual process, so that people will use it rarely. The prime intention here is to maintain a history of events and the current status, and never to lose it.

While your to do list, sticky notes on the refrigerator, or PDA may be a great personal ticketing system for simple lists of things to do, these tools are mediocre at best as a ticketing system for larger projects. Taking a numbered ticket at the supermarket before you can buy meat and cheese at the deli counter is another instance of a short-term but effective system. The same applies to the systems installed at railway stations and doctors' offices.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Although ticketing systems come in several flavors, most are designed for a single application. Typical applications, and some of the ways in which a ticketing system can explicitly help, are explained next.

Running operations support in a production environment can be very confusing. For example, if a bank financial trading system goes down, the online replacement (hotswap) system needs to step in and take over. Even if this works smoothly, there will be lots of people running around screaming like headless chickens. Under these circumstances it is very easy to see how a fix to a less critical application could be missed or delayed.

You can use a ticketing system to assign tasks as they come in to the next available operative. Tasks which have a higher priority or are critical in nature get fixed first. Simply fixing the current emergency is not enough, though. There needs to be a system in place which tracks the outstanding tasks—the ones temporarily on the back-burner—and identifies which are the most important to solve next. This is what the banks do and for good reason—they work in a permanent state of paranoia. The need for a priority list like this is not limited to banks. It applies to whatever is critical in your environment.

A representative of the company is informed of a potential sales lead. This information might come in many forms: a note, an email, a telephone call request, person who hears of a requirement that needs fulfilling, a personal recommendation. What form the lead takes doesn't really matter. The important thing is to not miss the opportunity to close the sale.

If you have a sales lead tracking system in place, you can see which leads are still open and need more work. You also can see which salesperson brings in the most leads, and perhaps most important, which salesperson successfully closes the most leads. This information is immediately available at all times via a number of configurable report options.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

We covered the essential bones of a ticketing system, now we'll look at some of the features that make up a succesful solution. All ticketing systems should have the following qualities:

Accessibility: A ticketing system should be simple to access from wherever you are going to access it. Programmers and programs will want a CLI (Command Line Interface), and users will want a GUI (Graphical User Interface). An example of a good choice for a GUI would be a thin client using the HTTP protocol across an Intranet or the Internet. This ensures that anyone with a web browser can use the system, and it doesn't require vendor-dependent client software with software upgrades and rollouts to handle.

Using the web as a front-end also ensures the client is platform-agnostic and works on Unix machines, Windows desktops, VMS hardware, Mac OS laptops, mobile phones, and all the many other variants around the world which support a web interface.

Besides a GUI, users will probably also want an email interface, so that they can receive alerts about system activity, like when a ticket they submitted is resolved.
Ease of use: The system should be easy to use. This means it should be intuitive to enter data, update the status, add interested parties, and assign scripts to certain events to modify the flow of a ticket to suit your particular requirements.
Multiuser: The application needs to be able to handle more than one user at a time, both at the user level and at the administrator level. Any number of people in an organization must be able to enter data of people in an organization to enter data and open tickets at the same time. Equally, multiple administrators must be able to modify things like scripts and status flags at the same time, and not be needlessly restricted by waiting for someone else to complete their changes or logout before they can do any work. A help desk team, for example, may find themselves quite busy receiving, triaging, and resolving customer requests.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Ticketing systems are good for multiple purposes and for many different people in different circumstances. Let's step back from the company or group perspective and look at how a ticket system benefits individuals.

From a personal perspective, a ticketing system enables you to collect tasks in a list, assign a priority or status to it so the system can automatically order the list, and more or less forget about it until it's time to work on it. Deciding what to do next is simply a matter of looking up the most critical item and doing that task. The system decides on your behalf what is the most urgent task based on attributes you set.

A ticketing system also helps you manage your time more efficiently and avoid working on three or four things at once and not getting any of them done. You simply do the current task, mark it closed, and move on down the list. This is a bit like a shopping list: you can go to the checkout when everything on the list—the prerequisites for this shop—is in the basket. Once the checkout phase is complete, you move on to the next shop. Millions of people do this everyday, all around the world. They are using an unsophisticated ticketing system, the shopping list, which is ideal for a simple and solitary activity.

However, if you are involved in a large organization, you may work with a number of people from separate departments, and your job may involve multiple different tools and interrelated tasks. A ticketing system can simplify your complex and interrelated tasks to behave like a shopping list for your environment. Select an open ticket, work through the involved tasks, if there are any unfinished dependencies close them first, then close the parent ticket.

Divide and conquer, simplify and close.

Perhaps you manage a team of people, all working on vaguely related tasks. Each time a new task arrives for your department, you assign it to one or more people based on their apparent availability and skill set. The task may be a customer request, a production change, a system failure bug report or whatever it is that your department handles.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Although you may want a ticketing system because it will make handling and tracking tasks so much easier, the first step is to persuade the right people. You need enthusiasm for the solution across the organization.

The people who pay for it come first—management has to have an interest. They need to see the benefits for their business, their customers, and their bottom line.

Any of the points described in the section "Ticketing Helps Everybody" might help convince a manager that his workforce could be more productive with less resources. A ticketing system can help handle multiple requirements to ensure a smooth operation, save time, avoid missing tasks, prevent less critical work from impeding the important work, and make the entire workflow more efficient.

Last, implementing a ticketing system is an inexpensive solution with many rewards throughout an organization. It enables managers to track activity in a complex environment—knowledge is power.

An enthusiastic manager is not enough, an excited staff is essential to the new process, too. One of the many reasons for individual members of a team to be keen on having a ticketing system in place is that they no longer need to inform a whole tree of people of the status of a particular chunk of work.

The familiar cries of: "Let me know when you've finished," "Don't interrupt me now, can't you see I'm busy, . . ., and "When you've done X, I'll tell you what to do next" need never be heard again. Once a ticketing system is in place, anyone in the team can pick up an outstanding piece of work with the highest priority and deal with it. They know no one else is going to start work on the task at the same time, because they are the owner of the task. No one needs to ask about progress, because everyone knows it is finished when the status is changed on the team web site. There may even be a customizable email to all interested parties. No more treading on each other's toes.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

RT is designed not only to handle all the scenarios explored above, but it also is flexible enough to accomodate almost any variation with little or no specialized knowledge.

RT runs on a number of different mainstream platforms, including various flavors of Unix, Linux, Windows and Mac OS. RT supports several popular database backends: MySQL, PostgreSQL, and Oracle. Finally, RT uses Perl—a language familiar to many programmers and systems administrators—to make local customization easy.

RT also has a great user and developer community, with active email lists and a handy wiki (http://wiki.bestpractical.com/). And because RT is open source software, you are free to extend and change the core product to suit your needs.

This chapter has described what a succesful ticketing system needs to support a satisfied user base, without focusing on any particular tool or solution. The rest of this book gets down to the nitty-gritty and describes how to use RT itself, from typical installation scenarios to detailed configuration files, and from the commandline to the web-based GUI interface.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Before you can make use of most of the wonderful advice and tricks in this book, you need a live RT instance running. If you already have an installed and running RT instance, skip to Chapter 3. In many ways, the initial installation of RT is the hardest part. RT is a complex Perl application with many dependencies—once all of those dependencies are in place, RT installs easily. Most of the time installing RT is spent installing those modules.

RT was designed to run on UNIX and UNIX-like systems. This means Linux, Solaris, FreeBSD, IRIX, HP/UX, Mac OS X, and similar systems. If your operating system of choice has pre-built packages for RT, that is the easiest way to install it. These third party packages are contributed and don't come from the RT developers. As of this writing, packages are available for Debian, FreeBSD, RedHat, and Mandrake Linux. There are some downsides to these packages: they may put files in unexpected locations to conform to packaging requirements, and they also may be out of date.

RT also runs on Windows. It is experimental and unsupported, so this chapter won't cover it, but it generally works. All of the component pieces (Perl, Apache, and MySQL) are available natively. The easiest way to get it running is to use Autrijus Tang's pre-packaged version of RT for Windows, which includes all the component pieces in one convenient installer. Download it from http://wiki.bestpractical.com/?WindowsOSInstallGuide.

Before you begin setting up RT, you need to satisfy a few requirements. RT is complex, and the requirements are fairly strict, as Perl applications go.

You must have a recent version of Perl installed. RT will run on older versions of Perl, but bugs in the Unicode implementation in older versions may cause data corruption. (And you really don't want to have to explain that to your boss.)

You do not need to install the same Perl that you use for RT as your system-wide version of Perl (i.e., as /usr/bin/perl). You can install it off to the side, in

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Before you begin setting up RT, you need to satisfy a few requirements. RT is complex, and the requirements are fairly strict, as Perl applications go.

You must have a recent version of Perl installed. RT will run on older versions of Perl, but bugs in the Unicode implementation in older versions may cause data corruption. (And you really don't want to have to explain that to your boss.)

You do not need to install the same Perl that you use for RT as your system-wide version of Perl (i.e., as /usr/bin/perl). You can install it off to the side, in /usr/local or wherever you'd like. If you choose to use mod_perl, it must be linked against this installation of Perl.

If the server running RT also runs other services (especially other mod_perl applications), you might want to create an installation of Perl specifically for RT to ensure that there are no dependency or version problems.

Ultimately, RT is all about its database . You have several options here:

MySQL 4.0.14 or later, with InnoDB support enabled (http://www.mysql.com/)
PostgreSQL 7.2 or later (http://www.postgresql.com/)
Oracle 9iR2 or later (http://www.oracle.com/)
SQLite (http://www.sqlite.org/)

RT runs equally well on MySQL and PostgreSQL. Oracle support is relatively new, but it should be as stable as the MySQL and PostgreSQL. An option for development is SQLite, a lightweight single-file database engine. We don't recommend you run it in a production environment, because it doesn't support high levels of concurrency well. Check the README file that comes with RT to see if the latest version supports any other databases. You should choose which database to use based on what's familiar to you and what resources you have available.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Get yourself a comfortable chair, a nice drink, some free hard disk space, and sit down for an hour or so of module building and configuration to install RT.

Like most database driven applications, RT is relatively resource intensive, especially on RAM. The more memory you can afford to dedicate to RT and its database server, the snappier it will feel and the happier your users will be. Fast CPUs and disks will help as well.

Also in this step, you should install the appropriate webserver and database, if those aren't installed yet.

There are good O'Reilly books on each of the supported databases, including Managing and Using MySQL, Practical PostgreSQL, and Oracle Essentials. Many of these books are also available on Safari, O'Reilly's online library, which makes searching convenient. You can access Safari by going to http://safari.oreilly.com.

You can find information about the latest RT releases from the official RT download page at http://www.bestpractical.com/rt/download.html. In addition to the locations for packaged releases, this page also contains instructions on how to download the latest development copy of RT.

The latest stable release of RT is always available as http://download.bestpractical.com/pub/rt/release/rt.tar.gz, so you can grab that now, and place it in /tmp.

With the tarball now in /tmp, unpack it with gunzip or an equivalent utility on your system:

    # gunzip -c rt.tar.gz | tar xvf -

This creates a directory named rt-3.x.x, where 3.x.x is the version of RT you downloaded. Make that directory your current working directory:

    # cd rt-3.x.x

Take a moment to read through the README file in your new RT directory. This file covers the basics of the installation, with brief instructions on how to do the install. More importantly, this file is the canonical location for updates to the installation procedure. If you are using Oracle, you'll also want to read the Oracle-specific instructions in the file

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The primary configuration file for RT is etc/RT_SiteConfig.pm, which is based on etc/RT_Config.pm. You should never edit etc/RT_Config.pm. It contains default values and will get overwritten during upgrades. However, any changes you make in etc/RT_SiteConfig.pm will take precedence.

RT has many configuration options, but most sites only need a few to get up and running. For more advanced configuration options, see Chapter 7 and Appendix E.

The data in RT_SiteConfig.pm can be in any order. You should place things in logical groupings, so that you can easily find them. The definitive reference on the possible configuration options for any particular version of RT is RT_Config.pm.

Once you've finalized the configuration for your new RT instance, be sure to back up RT_SiteConfig.pm somewhere safe. Other than the database, this is the single most important file in your RT installation, and complex configurations can be difficult and time-consuming to recreate manually.

There are some options you must configure. They are site-specific information.

The $rtname option is a short, unique name for this particular RT instance. It appears in the subject line of emails, so the RT instance can determine that the ticket was intended for it. Do not choose a generic name like "support" or "tech" for your $rtname, because this has the potential to conflict with other RT instances. A short version of your company name or its acronym are good examples.

    Set($rtname, "examplecorp");

$Organization should be a unique identifier for this particular RT instance, similar to a domain-name. $Organization is used for generating message identifiers and linking between RT instances. It does not necessarily have to be a valid hostname.

    Set($Organization, "rt.example.com");

Once you chose a $rtname and $Organization, you will need to be very careful about changing them, because RT uses them internally to maintain data structures.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Now that you have RT configured, it is time to configure your webserver. In the previous stage you set $WebBaseURL and $WebPath to where in "URLspace" you plan to have RT installed. Now we'll tell Apache about those values. (If you are not using Apache, you will need to extrapolate from the FastCGI section below.)

A common configuration for RT is to place it on its own VirtualHost, such as on rt.example.com for the example.com organization.

Use the following configuration in your httpd.conf:

    <VirtualHost *>
       ServerName rt.example.com
       DocumentRoot /opt/rt3/share/html
       AddDefaultCharset UTF-8
     
       PerlModule Apache::DBI
       PerlRequire /opt/rt3/bin/webmux.pl
     
       <Location />
           SetHandler perl-script
           PerlHandler RT::Mason
       </Location>
    </VirtualHost>

You will need NameVirtualHost * earlier in your httpd.conf unless you are using IP-based virtual hosting. (In that case, specify an IP address in place of the *.)

That configuration corresponds to the following lines in RT_SiteConfig.pm.

    Set($WebBaseURL, "http://rt.example.com");
    Set($WebPath, "/");

Using a separate virtual host isn't required. You can place RT at any location on your webserver. The following example places it at /rt3/:

    Alias /rt3 /opt/rt3/share/html
    <Location /rt3>
        AddDefaultCharset UTF-8
        SetHandler perl-script
        PerlHandler RT::Mason
        PerlModule Apache::DBI
        PerlRequire /opt/rt3/bin/webmux.pl
    </Location>

If your webserver is www.example.com, these would be the RT_SiteConfig.pm entries:

    Set($WebBaseURL, "http://www.example.com");
    Set($WebPath, "/rt3");

Section 2.3.5.1: mod_perl 1.x v. mod_perl 2.x

In choosing between mod_perl 1.x and 2.x, there are no hard and fast rules. mod_perl 1.x is several years old and is known to be very stable. mod_perl 2.x is cleaner, faster, and sits on top of the more powerful Apache 2 core.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Depending on your configuration, you might not be able to, or want to, run RT on your main webserver. One solution to this problem is to use a proxy in front of it. Figure 2-1 shows a proxied RT server. Apache 2.x, beyond being a webserver, also can function as a high-performance proxy.

There are several reasons you might want to do this:

First, only one instance of a mod_perl 1.x application can run inside Apache at a time, because there is a shared Perl interpreter. Multiple instances of an application can conflict with unexpected and undesirable results. A proxy can be used to map multiple instances into one URLspace.

Apache 2.x and mod_perl 2.x doesn't have this limitation. Perl interpreters can be bound to VirtualHosts or Locations with PerlOptions +Parent .

Second, Perl applications use a lot of RAM, and all Apache processes will end up allocating this RAM. If you also are serving static content, the memory usage will be high, thus limiting the number of Apache processes a machine can support and throughput..

Third, a proxy can allow your server to serve more requests. The back-end server won't need to buffer for a slow network connection and can quickly return to serving requests. This means you will need fewer heavy mod_perl processes running.

Finally, RT is designed to be a secure application, but as with any piece of software there is always potential for a hole to be found. By using a proxy to a dedicated Apache server, RT can be isolated from other services on the system. A compromise of RT would not imply instant access to the rest of the web system.

Apache 2.x is a good candidate for this, as it's a bit faster and a little more flexible than Apache 1.x.

In your front-end proxy webserver, use the following configuration, after making sure that mod_rewrite and mod-proxy loaded:

    <VirtualHost *>
        ServerName rt.example.com
        RewriteEngine On
        RewriteRule ^/(.*)$ http://localhost:8284/$1 [P,L]
    </VirtualHost>

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Configuring RT to send mail consists of a few steps. First of all, make sure that the server has a working MTA (Mail Transfer Agent).

Common MTAs include sendmail (http://www.sendmail.org/), postfix (http://www.postfix.org/), and qmail (http://cr.yp.to/qmail.html). Most Unix-based operating systems ship with at least one of these available by default (Linux distributions have almost all of them available, in fact). Installing and configuring the MTA is beyond the scope of this book, but the vendors' web sites all provide detailed installation and configuration instructions.

Once you have the MTA installed and set up to send mail, you need to tell RT to use it. Look in the RT_Config.pm file, and copy the following lines to RT_SiteConfig.pm:

    Set($SendmailPath , "/usr/sbin/sendmail");
    Set($SendmailArguments , "-oi -t");

Since it's the traditional location for sendmail, /usr/sbin/sendmail will usually work. Most other MTAs respect this tradition through compatibility wrappers. If /usr/sbin/sendmail does not exist, try /usr/lib/sendmail.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Incoming mail destined for RT is processed through RT's mailgate, conveniently called rt-mailgate. When it is invoked, this script parses the incoming message, and transfers it to your main RT server for processing. The mailgate does not have to run on the same machine as your main RT server, as long as it can communicate with it via http or https.

MTAs have the ability to pass mail destined for particular addresses to a program instead of to a mailbox, and RT utilizes this. Unfortunately, this feature is configured differently for different MTAs. Most of them support Sendmail's traditional aliases format, so that's the format we'll be using for the examples in the following sections. A notable exception is qmail, which will be covered separately.

Several different command line options are supported by rt-mailgate (as shown in Table 2-3).

Table 2-3: Mailgate options
Option	Meaning
`—action=` comment\| `correspond`	Select whether this email should be processed as a comment or correspondence.
`—queue` =QUEUENAME	Select which queue to process the email into.
`—url=` URL OF RT INSTANCE	The URL of your RT instance.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Not everyone's installation goes perfectly the first time. There are some common problems that may occur.

All necessary Perl dependencies must be installed. Make sure you've run configure with the proper arguments followed by a make testdeps. If there are any failures, you will need to resolve them.
If you have odd email issues, double check that you have configured Sendmail's smrsh by symlinking /opt/rt3/bin/rt-mailgate into /etc/smrsh.

Some places to go for help are the rt-users mailing list on http://lists.bestpractical.com, Chapter 8, or the RT Wiki at http://wiki.bestpractical.com.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

At this point you should have a working RT instance. Restart your Apache, and test it out by pointing your web browser at whatever URL you've specified.

The default administrator user for RT is called root and the password is password. After you log in for the first time, you will want to change this by clicking on "Preferences" in the upper right hand corner.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In this chapter, we'll give you a basic overview of how to use RT's web interface. This is the primary interface to RT for both users and administrators—you can access all of RT's features and configuration options through it. Once you've read this chapter you should be able to log into RT and find, modify, and resolve tickets. We'll also touch on what you can use email for and how it integrates with RT. The RT command-line tool, covered in Chapter 4, also performs many of the same tasks you'll learn in this chapter.

This chapter assumes that you are running your own RT installation. If you are using an existing installation to learn about RT, be careful about creating new tickets. You don't want to broadcast your test tickets inadvertently to the entire user base. For experimenting, you might be interested in the standalone server that ships with RT. The standalone server is a small web server written in Perl. Because it can handle only a limited number of concurrent web clients, it is not really suitable for anything other than testing. However, it is very useful for that, because it requires no other web server to be installed. See the sidebar "Standalone Server Mode" in Chapter 2 for instructions on how to start the standalone server.

If you are working in an environment where there is an existing RT installation, your RT administrator most likely will give you a username and password as well as instructions on where the RT login URL is. When you first connect, you will see a login box, something like the one in Figure 3-1.

If you have a brand new RT instance, you can log in with the default username root and password password. You should change this password immediately by clicking on the Preferences link, especially if your RT instance is accessible from the Internet.

Once you've successfully authenticated yourself to RT, you will see the home page with the title "RT at a glance." This page, shown in Figure 3-2, displays a snapshot

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

If you are working in an environment where there is an existing RT installation, your RT administrator most likely will give you a username and password as well as instructions on where the RT login URL is. When you first connect, you will see a login box, something like the one in Figure 3-1.

If you have a brand new RT instance, you can log in with the default username root and password password. You should change this password immediately by clicking on the Preferences link, especially if your RT instance is accessible from the Internet.

Once you've successfully authenticated yourself to RT, you will see the home page with the title "RT at a glance." This page, shown in Figure 3-2, displays a snapshot

Figure 3-1: RT login box

of RT as it applies to you. It gives you easy access to the tickets you own, tickets you've requested, tickets in the queues you watch, and interfaces for finding existing tickets and creating new ones. Many items on this page are clickable—such as ticket numbers, ticket summaries, and queues—and take you to ticket displays or queue listings.

Figure 3-2: RT at a glance

The display is easy to customize and extend, so don't be too alarmed if what you see is not exactly the same as what these screenshots show. Since this home page is intended to be a clearinghouse of information, administrators may add extra queue displays or links to documentation, internal policies, and canned searches. The next major release of RT should make this sort of configuration.

Along the left side of the page is the main site menu. This menu has links to all of the major things you can do with RT: search for tickets, configure RT, change your preferences, and so on. Configuration is covered in more depth in Chapter 5, and customizing your preferences will be covered in Chapter 6. The rest of this chapter concentrates on the Tickets menu item.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You can create a ticket from anywhere in RT; the top of every page has a small form with a button labeled New Ticket in and a drop-down menu listing the queues you can access. Select the queue in which you want to create a new ticket, and click the New Ticket in button. It will take you to the new ticket form shown in Figure 3-3.

Figure 3-3: Create a new ticket (basic)

The two most important fields in this basic form are the subject of the ticket and an entry box for a description; these are the first items that people see when they look at your ticket. The subject is displayed on the main page with no context, so you should make sure that it is clear and concise. The description field is the primary explanation for what the ticket is about, so you should take care to include all the relevant information. Also keep in mind how the description will be used. For example, tickets created in an Emergency queue outside of business hours might send a message to the on-call operator's SMS device. A ticket that does not get to the point within the SMS character limit will be pretty frustrating for everyone involved.

Fill in all the appropriate details, click the Create button, and you'll have a new ticket. Congratulations!

There is a quick ticket creation box at the bottom of the home page that instantly creates a new ticket with an empty description.

Tickets are identified by number. On a fresh install, the first ticket you create is numbered 1. Every new ticket after that gets a number one higher than the previous ticket. If your RT instance is configured to send mail when a ticket is created (as it is by default), then you should get an email message shortly with a summary of the ticket you created. This message tells you the number that was assigned to the new ticket and provides a URL to the ticket display form. Keep this URL, as you'll need it shortly.

When a new ticket is created, RT may run some user-defined actions—called

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The important part of handling a request is doing the work, but once you've completed the task, you need to update the ticket to reflect your work. So how do you update a ticket? First, you need to go the main display page for that ticket. Clicking on a ticket's ID or Subject from the home page (Figure 3-2) is one way to get there. If you click on the name of a queue in the Quick Search box on the right of the home page, you can preview all the tickets in that queue and select your ticket from the list. You also can enter a ticket number in the search box on the top right of every page, and click Search to get there.

A fourth way to get to the ticket display page is with a direct link in the browser. The URL to display a ticket always will be in the format http://< RTSERVER >/Ticket/Display.html?id=< NUMBER >, where RTSERVER is the root of your RT instance, and NUMBER is the ID of the ticket. The notification emails RT sends when a new ticket is created will contain this URL unless your administrator has removed it from the template. If none of these help you, and you don't know the ticket number, you can use the search interface to find your ticket. RT's search UI lets you build complex queries with relative ease; see "Searching for Tickets" later in this chapter.

Once you get to the ticket's display page, you are confronted with a colorful interface, which shows the major groups of ticket attributes. The metadata associated with a ticket is divided into four main categories—Basics, Dates, People, and Links—each of which tracks a different aspect of the ticket, as in Figure 3-4. You can edit each category individually by clicking on the category name in the main display area or by clicking on the category link in the sidebar on the left. The Jumbo form linked from the sidebar edits all attributes at once. The Jumbo form is quite busy compared to the other pages, but it has the advantage of allowing many different types of updates all at once.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

RT records two main types of transactions: attribute changes and correspondence. Correspondence and comments are what adds content to a ticket and covers all the replies and user feedback that RT collects. While you can change many different types of attributes, most of the interesting content in your RT installation will come from correspondence. Comments are generally intended as private or internal correspondence about a ticket. RT is very flexible and the exact mechanics will depend on how your administrator has configured RT, but usually correspondence is visible to end-users and comments are not.

You reply to a ticket by clicking the Reply link at the top right of the ticket display page or beside an individual item in the ticket's history. Figure 3-5 shows the form for responding to tickets. The same form creates either replies or comments, depending on what you select for Update Type. From this form, it's simple to reply to an end user, mark down how much time you spent composing your response, and close the ticket.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Each ticket has a priority. Priority is a way to indicate relative importance. It can be any integer. Most organizations use the range 0-100. Every queue has a default priority for new tickets if you don't explicitly set one. To escalate the priority of a ticket, set the priority of a ticket to a higher number. The priority field is in the Basics category, shown in Figure 3-6.

Figure 3-5: Ticket reply

Figure 3-6: Ticket priority

Queues can be configured to automatically adjust the priority of tickets over time. Based on the current priority of the ticket, the priority escalates every day so that it reaches its final priority on a given due date.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Tickets can have an owner—the user responsible for working on the ticket or for coordinating the work. To assign a ticket to someone, go to the People form from the ticket display page, and select the user from the Owner drop-down list, as shown in Figure 3-7. This list contains the usernames of all the users allowed to own tickets in the ticket's current queue.

Figure 3-7: Assigning a ticket

You can assign only tickets that you own or that are unowned. If you need to reassign a ticket that you do not own, you can steal the ticket and then assign it to someone else. Tickets you can steal will display a Steal link next to Reply and Comment in the upper right corner of the ticket display page. Not all users have access to steal tickets, see "ACL" in Chapter 8.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

When you are satisfied that the ticket you are working on is finished, you can change its status to resolved, so other users know it doesn't need any more work. This process is known as resolving the ticket. To modify a ticket's status, just click Resolve in the upper right hand corner of any ticket page, as shown in Figure 3-8.

The form used for resolving a ticket allows you to send a reply to the ticket's requestor and watchers.

Figure 3-8: Resolving a ticket

Certain scrips run when a ticket is resolved. The default scrips send mail to the ticket's watchers.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|

Table of Contents

Section 2.3.5.1: mod_perl 1.x v. mod_perl 2.x