RT 3.0.0 Release Candidate 1

RT Developers
1

I’m pleased to announce RT 3.0.0 Release Candidate 1. Below is a draft
of the high-level release notes for RT 3.0.0. The exact release date for
3.0.0 will be determined by feedback during the release-candidate
process, but it’s very close. The beta process has been amazingly
smooth.

Get your hot, fresh release candidate at:

http://bestpractical.com/pub/rt/devel/rt-3-0-0rc1.tar.gz


Best,
Jesse

RT 3.0.0 represents over a year of work extending and enhancing RT 2.0.
It’s a significant new release with major new features, including:

* The new web interface is prettier, easier to use and also 
  more standards compliant.
* RT now includes a flexible "approvals" system that lets you define 
  site-specific policies to require approval before certain classes 
  of ticket can be resolved.
* The mail gateway has been rebuilt to use an RPC mechanism to 
      talk to your RT server, rather than needing to run setgid on 
  your RT server.
* Groups and access control have been completely reworked. 
* Group membership is now recursive, so you can create groups 
  which contain other groups.
* The installation process has been overhauled. Autoconf
  (./configure) make installation easier than ever before.
* Users can now delegate their rights to other users.
* Full "custom field" support has replaced RT 2.0's "keywords". 
  Custom fields can now contain arbitrary text, as well as 
  "Select from list".
* RT now stores all data as Unicode internally, so it's much 
  easier to work with multiple languages
* RT's core and web interface has been fully internationalized. 
  RT now speaks: English, French, German, Spanish, Portuguese, 
  Dutch, Finnish, Czech, Russian, Japanese, Traditional Chinese, 
  and Simplified Chinese.
* RT even easier to extend than ever before: The API is much 
  better documented, the web interface includes a new "Callbacks" 
  mechanism to let you embed your own components without touching 
  a line of RT's source code. The core libraries include a new 
  "Overlay" system to let you override RT's core functionality 
  at the subroutine level.
* The 'scrips' system is even more powerful. Now administrators can 
  create custom scrips right from RT's web interface.
* RT 3.0 is much better tested than any previous release of RT.
  Each release must pass a suite of over 750 tests before being 
  released to the public.
* There's a full manual.
* And, of course, there's lots more.

Request Tracker — Best Practical Solutions – Trouble Ticketing. Free.
rt-announce mailing list
rt-announce@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-announce

2

These are my notes from installing RT 3.0 from scratch, from
someone who hadn’t touched RT since 1.0.7 . . .On Sat, Mar 15, 2003 at 12:58:24PM -0500, Jesse Vincent wrote:

–
Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.

Just for laughs, I suppose you envisaged

Request Tracker... So much more than a help desk — Best Practical Solutions – Free Trouble-Free Trouble Ticketing
Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing, Free & Trouble-Free

:slight_smile:

OK, so it’s not quite trouble-free, just almost:

Manual lacks an example for httpd.conf and fastcgi the way it
has for mod_perl. Found

http://lists.fsck.com/pipermail/rt-doc-workers/2001-October/000036.html

which is not bad but I would have liked a pointer to using
FastCgiIpcDir (Apache directive, place probably anywhere after
LoadModule/AddModule, defines location of FastCgi temporary
files). OK one shouldn’t be installing FastCgi for the first
time while installing RT for the first time :slight_smile:

The dependency scripts don’t scream that suidperl is absent,
had to figure that out by googling for the httpd error message.
Isn’t that easy to test for? And yes, I know it’s a FAQ, I’ve
seen it often enough on the lists, but no I did not recognize it
when it was under of my nose.

Also (for the Google record),

Can’t locate {snip install path}/etc/RT_SiteConfig.pm in
@INC (@INC contains: {snip install path}/lib {snip install
path}/local/lib {snip other paths NOT including install
path/etc} ) at {snip install path}/lib/RT.pm line 105.
Compilation failed in require at
{snip install path}/bin/mason_handler.fcgi line 28.

Just wrong permissions on RT_SiteConfig.pm, grrr. Wasn’t
readable as the unprivileged users apache and RT were running
as, had created it as root. Wouldn’t it be a good idea to
follow or replace the “-f” at lib/RT.pm:104 by something that
tests readability? Crash screaming something understandable
if RT_SiteConfig.pm exists but is not readable? Perl’s error
message is far from understandable!

Well, that certainly wasn’t much, and most of it me not really
knowing what I was doing 8-D Congratulations!

HAND
#include <std_disclaim.h> Lorens Kockum