RT

Keeping track of things

Hi, I’m Jesse

• jesse@{ fsck | bestpractical } .com

• President of Best Practical Solutions

• Perl hacker

• Recovering sysadmin

Overview

• What RT is

• Who uses RT

• How to use RT

• How RT is put together

• How to extend RT

What RT is (buzzwords)

• Issue tracking platform

• Enterprise grade

• Open source

• Internationalized

Who uses RT

Usage scenarios

– Bug tracking

– Customer service

– Helpdesk

– Network Operations

– Project Management

– Collaboration (OSCon)

– Weblog

The RT mindset

– it’s a historical record and a project manager

– Everything is a ticket

– No task is too big

– No task is too small

– Update your tickets often

– It’s better to have a vague ticket than no ticket

– Don’t send yourself email reminders, send them to RT

How to use RT

By email

• End users don’t need to do anything special

• Except feel like they’re getting special attention

• RT magically routes mail to the people who need to see it

On the web

How RT is built

Layer cake

Database

• RT is composed of over a dozen types of objects, all of which interrelate

• Building your own relational database out of BDB or flat files on disk isn’t our idea of fun

• Organizations want to be able to use their own tools to query RT

• RT uses an SQL backend

RT’s database schema

RT Core• Principals

• Users

• Groups

• GroupMembers

• CachedGroupMembers

• ACL

• Links

Ticketing system• Queues

• ScripActions

• ScripConditions

• Templates

• Scrips

• CustomFields

• CustomFieldValues

• Tickets

• TicketCustomFieldValues

• Transactions

• Attachments

Writing directly to the database is wrong

– RT is a complex application with complex relationships between database tables

– Querying the database for reporting is OK, but usually unnecessary

– We’ve got a better way…

DBIx::SearchBuilder

– It’s an object-relational mapper

– It hides SQL from your application

• RT’s PostgreSQL and Oracle ports were completed without changes to RT, just to SearchBuilder.

– It lets you turn certain kinds of database into singleton and collection objects

– It’s kind of like Class::DBI

– (almost) every RT object is a DBIx::Searchbuilder::Something

SearchBuilder is simplicity

# Instantiate an empty ticket object$t = new RT::Ticket( $RT::SystemUser );

# Load the ticket we care about$t->Load( 42 );

# Print the ticket’s subjectprint $t->Subject;

Singleton Objects

• DBIx::SearchBuilder::Record takes care of – Creators

my $user = RT::User->new($RT::SystemUser);$user->Create(Name => ‘jrv’, EmailAddress => ‘jrv@s.ly’);

– Loaders$user->LoadByCols(EmailAddress => ‘jrv@s.ly’);

– Accessorsprint $user->Name;

– Mutators$user->SetName(‘jesse’);

– Destructors$user->Delete();

Collection Objects

• Every singleton has a corresponding DBIx::SearchBuilder ‘collection’ object

• Complex searches without raw SQLmy $users = RT::Users->new($RT::SystemUser);

$users->Limit(FIELD => ‘EmailAddress’, OPERATOR => ‘LIKE’, VALUE => ‘fsck.com’);

while (my $user = $users->Next) {

print “Found “.$user->EmailAddress.”\n”;

}

RT Core

The RT Core Objects

• DBIx::SearchBuilder::Record subclasses

– Ticket

– Queue

– User

– Group

– And Others

• ACE, Attachment, GroupMember, CachedGroupMember, Link, Principal, CustomField, CustomFieldValue, TicketCustomFieldValue, Transaction

Overlay and local classes

• Core database-access classes are autogenerated

– When the database changes, you don’t want to hand-hack code

– When you make changes to RT, you want your changes to persist seamlessly across minor version upgrades

• Most sites don’t track local source changes

• Even if they do, merging sucks

How Overlays work

eval "require RT::Ticket_Overlay";if ($@ && $@ !~ qr{^Can't locate

RT/Ticket_Overlay.pm}) {die $@;

};

eval "require RT::Ticket_Local";if ($@ && $@ !~ qr{^Can't locate

RT/Ticket_Local.pm}) {die $@;

};

Principals, Users and Groups

• Principals– Every User is a Principal– Every Group is a Principal– We can treat users and groups as

equivalent for ACL checks and Group Membership

• Groups can contain users and groups– Groups can’t contain themselves

Authentication

• RT has its own internal authentication system• RT needs to have a user object for any user before

they’re allowed to access RT– They are autocreated on email submission, if you grant

‘Everyone’ the right to create/correspond/comment on tickets

• You can tie RT into your own authentication source

ACL system

• ACLs can apply to any DBIx::SB::Record

• Any Record object type can define what rights it supports

• Rights can be granted to any user or group

• Other systems that drop on top of RT can use the ACL system

Delegation

• Supports basic delegation of rights

• Doesn’t support “partial” delegation of a given right

• Doesn’t support “redelegation of rights”

• When a user’s right to do something is revoked, delegates also have right revoked

ACL Queries

• Currently supports

– Does $principal have $right for any object in @objects?

– What principals has $right for $object?

• Should also support

– What rights does $principal have for $object

Mason application server

• RT’s web interface is built on HTML::Mason

– Easy to start hacking on, especially if you know perl

– Fast

– Flexible

• Multiple Component Roots

– System

– Local

Handlers

• mod_perl

• FastCGI

• SpeedyCGI

Brief comparison to JSP,ASP,PHP,TT

• Mason is like ASP or JSP, but for perl

• Unlike the Template Toolkit, it’s all perl, all the time

• Unlike PHP, there’s a real language behind it

I18N and L10N

Internationalization

Building blocks

– UTF8/Unicode– Encode– Locale::MakeText{::Lexicon,}

String Extraction

• Overview • Core

$self->loc(“Created ticket [_1]”, $self->Id);

• Code In Masonloc(“Created ticket [_1]”, $ticket->Id);

• Text In Mason<&|/l, $ticket->Id &>Created ticket [_1]</&>

• Getting the strings into the .po files – tool/extract-message-catalog

Localization

Adding a new translation

– Basic internationalization for languages without cases/aspects

– Extract a fresh .po file• Example string from .po file

#: html/Admin/Users/Modify.html:80msgid "Access control"msgstr "Toegangscontrole”

– Translate .po file– Check your work

Corporatization

• Localization can be useful just within an organization.

• Every organization has its own jargon

• It’s a “request, not a ticket”– PO files can be ‘overlaid’ just like libraries

How to extend RT

User Visible API

• All RT tools use the API we export to the world

– rt-cron

– web frontend

– SOAP server

• perldoc RT::Ticket

• perldoc RT::Ticket_Overlay

RPC Mechanisms

• Scraping

• REST

– Mail Gateway

– CLI

• SOAP

– Net::RT

Some code examples

RT Preamble

#!/usr/bin/perl -w use strict;

use lib ("/opt/rt3/lib", "/opt/rt3/local/lib");use RT;

# Load the config fileRT::LoadConfig();

#Connect to the database and get RT::SystemUser loadedRT::Init();

A simple tool to resolve a ticket

[preamble]use RT::Interface::CLI qw(GetCurrentUser loc);use RT::Tickets;

my $CurrentUser = GetCurrentUser();die loc("No RT user found.") unless ($CurrentUser->Id);

my $ticketid = shift;my $ticket = RT::Ticket->new($CurrentUser);$ticket->Load($ticketid);die loc(“Ticket not found”) unless ($ticket->Id) ;my ($tid, $msg) = $ticket->SetStatus(‘resolved’);print $msg;

A simple web tool

<%init>my $tix = new RT::Tickets

($session{‘CurrentUser’});$tix->Limit(FIELD => ‘Owner’, VALUE =>

$session{‘CurrentUser’});</%init><h1><&|/l&>My tickets</&></h1>% while (my $ticket = $tix->Next) {<%$ticket->id%>: <%$ticket->Subject%> <

%loc($ticket->Status)%><br>%}

Testing

• Make regression tests– database setup– core code– mail gateway– web ui

• It doesn’t yet test– with multiple databases– with multiple perl versions

Development Methodology

• Core controlled by Best Practical

• Linux-style stable and development branches

• Development roadmap is driven by “enlightened itch-scratching”

• Archive of community contributed add-ons

Recommended reading

• Web UI– Mason Book

• Core– RT Style Guide– perldoc RT::Ticket– perldoc RT::Ticket_Overlay

• I18N– perldoc Locale::Maketext::TPJ13– perldoc Locale::Maketext::Lexicon

Getting in touch

• www.bestpractical.com– Find RT on the web

• rt-users@lists.fsck.com– Chat with other users

• rt-devel@lists.fsck.com– Get involved in development

• rt-3.0-bugs@fsck.com– Report issues you run into

• sales@bestpractical.com– Overworked? Lazy? Let us do it for you

• jesse@bestpractical.com– Hassle Jesse directly

Thanks!

• Got any questions?