It should come as no suprise to folks that we’ve been hard at work on
what will become RT 4.0.
We’ve been working hard to overhaul the entire codebase. The current
version of the web interface is only 10,000 lines of HTML shorter
(118kloc down from 128kloc), but the core libraries have shrunk from
68kloc of code to 54kloc.
At the same time, we’ve moved RT from its own homegrown application
framework to Jifty, Best Practical’s next-generation web application
platform. Jifty brings with it all sorts of new features which make it
easier to build out web services and web applications with less code and
easier support for modern Web 2.0 features.
If you download the RT 3.999 development branch today, you’ll find
a few major new features. The most visible of those is “Status
schemas.” In RT 4, you can define directed graphs of ticket states and
valid transitions between those states. You can associate one or more
queue with any status schema. At its simplest, this means that you can
now freely add or remove statuses from your RT instance through the web
interface. If you want to get a bit fancier, you can specify that "new"
tickets can move only to “open” or “rejected” and that “open” tickets
can only move to the “testing” or “rejected” states. This makes it
easier than ever to adapt RT to your existing process and workflow.
Under the hood, we’ve begun to generalize other parts of RT. While role
groups are still limited to “Requestor”, “Cc” and “AdminCc”, we’ve
mostly completed work that will allow you to define custom role groups.
(Exposing that functionality isn’t currently slated for RT 4.0)
There are a few fairly major projects in progress which we’re currently
planning for RT 4.0:
Most application configuration will move into the database, making it
easier for RT administrators to fully manage RT using the web interface.
TicketSQL has been extended as ‘tisql’, a new, more powerful query
language which will be available internally for all objects in RT, not just
Scrips are being replaced with a new workflow engine codenamed
’Lorzy’. Lorzy makes it possible to build out much more complex rules
than Scrips’ simple “If __ Then __” conditionals. Under the hood,
Lorzy is a fully sandboxable lisp-like functional minilanguage with
named, typed arguments and the ability to detect runaway rules and
limit individual rules by actor. In the future, we hope to also
expose Lorzy as a user-level scripting engine for RT.
Date and Time rationalization - We’ve been ripping out RT’s old and
fairly adhoc implementations of various bits of date and time and
replacing them with a shiny, new implementation based around Perl’s
There are a dozen other projects we want to undertake - We’re going
to try to hold out so we have something cool to show for 4.2, 4.4
We have a few additional bits of backward-compatibility we want to
break before declaring something as a 4.0 “beta” that we’d actually
like folks to test in production. We’re not there yet. I’ll tell
you as soon as we get there.
4.0 is a major new release of RT. Like the transition from RT 2.0
to 3.0, 4.0 represents a major break in backwards compatibility
with older versions of RT. When you look under the hood in RT 4,
you’ll see that the entire API has been overhauled to match more
common Perl style guidelines. The most obvious change is that the
API has been rationalized to lower_case_style from the previous
CamelCaseStyle, but there are numerous other changes throughout the
product’s internals. We’ve written more RT extensions than anyone
out there (as far as I know) and we’re very, very aware of just how
painful a major API change is. We have the beginnings of tools and
guidelines to help you make the transition with as little pain as
It should come as no surprise to you that I’m not announcing a
release date for RT 4.0.0 today, nor will I be doing so in the
immediate future. We have a long way to go before RT 4 will be
the recommended version of RT for a production or evaluation
deployment. Even once that happens, Rest assured that we’ll continue
to support RT 3.x for a good long time. Best Practical’s business
is built on helping our users make good use of RT and our other
products – We’re not about to cut off those of you using RT 3 in
RT4 Release MicroFAQ
Q: How can I help?
A: I’m glad you asked. http://wiki.bestpractical.com/view/RT4 has a
pointer to the RT4 source code. Check out the source. Then do any
of the following:
- Clean up code that you think needs cleanup. - Add or improve documentation. Find bugs. - Fix bugs.
Mail patches or bug reports to email@example.com.
Q: When will RT 4.0 be released?
A: How much money do you have?
Q: Why doesn’t RT 4.0 have feature XXX?