Request Tracker
by Robert Spier
|
Pages: 1, 2
The Guts
You may be thinking that RT is a horribly complicated piece of software, impossible to understand, use and extend. If you are, you're completely wrong. Through extensive modularization and a well thought out architecture and design, RT is quite easy to understand, use and extend.
RT2 is built upon standard modules that many people use. There isn't anything esoteric used; in fact, you may already be using many of the modules on which it depends.
But you might think that installing all the dependent modules might be a chore. Again, RT is smart. It comes with a script that uses the CPAN.pm module to retrieve and install the correct versions of everything it needs.
This is probably the hardest part of installing RT. (Assuming you have CPAN.pm configured properly.) You run "make fixdeps," and it all happens for you. It may be necessary to run it multiple times or install one or two modules by hand, but that's easy compared to manually installing almost 30 modules.
DBI DBIx::DataSource DBIx::SearchBuilder HTML::Entities MLDBM Net::Domain Net::SMTP Params::Validate HTML::Mason CGI::Cookie Apache::Cookie Apache::Session Date::Parse Date::Format MIME::Entity Mail::Mailer Getopt::Long Tie::IxHash Text::Wrapper Text::Template File::Spec Errno FreezeThaw File::Temp Log::Dispatch DBD::mysql or DBD::Pg
The most important module is probably DBIx::SearchBuilder. It
provides a standard mechanism for persistent object-oriented storage. By
using it, RT doesn't need to worry about the details of the SQL queries
to access its database. The details of DBIx::SearchBuilder are
beyond the scope of this article - in fact, they'll be covered in a
future perl.com article - but in a nutshell, your classes will subclass
the SearchBuilder class, and the module will take care of the
persistence for you. SearchBuilder also makes it easy to port RT to
your SQL backend of choice; since it's all done through the DBI, the
architecture is completely database-independent.
Configurability & Extensibility
Ninety-five percent of RT is configured via the Web interface. Once the system is up and running, most changes can be made through the Configuration menu. Everything from adding users to configuring automatic e-mail responses can be done there.
Because the Web interface is created using HTML::Mason, it's easy to
extend RT using the internal API. Whole pages or just individual Mason
elements can be easily overridden or updated. Common customizations
include specialized reports, user interface tweaks or new authentication
systems. Any trouble ticketing system will need adapting to the needs of
the local users, and RT makes it easy to do this. The API by which the
Mason site accesses the ticketing database is the same thing that all of
the interfaces use natively, so it's possible to completely re-implement
any interface from scratch - in fact, you can write your own tools to
access the system quickly and easily by using the RT::* modules in
your own code.
More Configuration Examples
|
Recently, to demonstrate the strength of RT as well as to provide a needed service to the community, Jesse Vincent, the author of RT, set up an RT instance for all perl modules on CPAN. rt.cpan.org showcases many features of RT.
For more information on rt.cpan.org, visit it, or see this article on use.perl |
Currently, I'm using RT for several different projects. Here are a few more details about each RT setup to provide you with more ideas and examples.
- Bug Tracking
As mentioned above, the perl 6 project is using RT to track bugs and todo items. Right now the Parrot project has one queue set up; this is a little slow at the moment, but will be ramping up as Parrot stabilizes. A custom report was written to show only items marked with the "Todo" keyword, so that we can update a Web page listing the things that need doing. The scrips are configured to keep the requestor in the loop with the progress of their issue. - Help-Desk
perl.org maintains many mailing lists, which means dealing with lots of users who have trouble subscribing, or more likely unsubscribing from lists. The list-owner@perl.org e-mail address is filtered into RT, where a ticket is created automatically. Thus, each user's case can be tracked. For this, we wrote a special template system that allows us to easily insert common answers into correspondence. - Project Management
This is similar to bug tracking, but doesn't require the same kind of notification or categorization. At perl.org we use our RT setup to track the status of a variety of internal projects, such as our CVS server and Web site development. - Personal Todo and Information Store
At home, I use RT as "yet another TODO list" and information store. Instead of cluttering my e-mail inbox, or stuffing things into folders where I might forget about them, I open tickets in my "personal RT." I can then categorize them and add comments to them. There are a range of different things I stick into RT, ranging from "Remember to look at this Web site" to "Get new cellphone." For the latter, I add comments that include the details of my research. I can easily access this from work or anywhere there is Web access.
More!
There's a lot more to RT than I've covered in this article. Some things I've glossed over include:
- Access control
RT has a sophisticated access control system that supports different levels of access to tickets based on a user's identity, group memberships or role. You can grant permissions globally or per queue. It's possible to configure read-only access or only allow someone to see tickets they requested. - Command Line Interface
There is a full-featured command line interface that allows you to do almost anything. This provides another way to script and customize things. - Scalability
Request Tracker is very scalable and is being used in production environments with several tens of thousands of tickets in the database. (Not on a 486, of course.)
Future Directions
The current version of RT2 is 2.0.9. The 2.1 development series will be starting soon leading toward 2.2. While nothing has been finalized, items on the table for 2.2 include better ACL support, more flexible keywords, asset trackin, and several other cool things.
Best Practical
Commercial Support for Request Tracker is available from Best Practical Solutions, LLC. Best Practical Solutions was formed by RT's author, Jesse Vincent, to sell support and custom development for RT. They do all sorts of customization, interfaces, and custom import tools.
Other URLS
http://bestpractical.com/rt/ - RT Site
mailto:sales@bestpractical.com - Support and customization inquiries
http://www.masonhq.com/ - HTML::Mason Site
http://rt.cpan.org/ - RT for every module in CPAN
