RT 3.0.4 is available for download

I’m pleased to announce the immediate availability of RT 3.0.4.

This release includes significant performance improvements for both MySQL
and PostgreSQL. Additionally it includes new support for packages which
extend RT. The upcoming release of RTFM 2.0 requires this new support.
Display of relationships between tickets and transactions which alter
them has been overhauled to be simpler and clearer.

We’ve included a number of UTF-8 fixes which improve the mail gateway’s
support for nested MIME email messages. There has been a report that
this fix can scramble UTF-8 characters in the subjects of comments and
replies to certain tickets.

With this release, we’re officially deprecating perl 5.6.1 and Mysql
3.23.x. Both have proven themselves to be unsuitable as infrastructure for
a stable RT 3.0 installation. Within the next 3 months, we’ll officially
drop support for them.

And of course, there’s the usual set of minor cleanups and improvements.

A full changelog follows.

Best,
Jesse Vincent

Change Log Sat Jul 12 04:24:41 2003

rt.3.D000, C0, jesse, Thu Mar 13 20:43:23 2003, RT: Request Tracker, branch 3.0.
RT: Request Tracker, branch 3.0.

Delta  Change   

 169    125	  CustomField rights checking was overly restrictive for users
	  without queue-specific rights
 170    126	  I18N mail testing was was being cavalier with the state of
	  acls after its testing.  (clone of 3.0.C167)
 171    127	  Ticket Update.html fix to not doubly load content
 172    128	  Fixing postgres sortorder bug unmased by searchbuilder fix
 176    129	  Applying POD patches from ourinternet (clone of 3.0.C173)
 177    130	  UTF8, Custom Field and text message rendering fixes from
	  ourinternet
 178    131	  #2843 Date relations were too strict in RT::Tickets searches
 179    132	  #2847: allow URI Resolver to render itself
 173    133	  ShowMessageHeaders; make headers clicky
 180    134	  use RTIR callbacks
 175    135	  Updating rt-setup-database to take acl and schema file names
	  on the commandline
 181    136	  Refactored Users::WhoHaveRight from Chris Audley at Blackrock
 182    137	  Download link in ShowTransaction
 185    138	  Fix for speedycgi disappearing database connections
 183    139	  #2873: Fix for insufficently agressive loop culling
 186    140	  Fix for nested email message parsing
 187    141	  Split the HasRight ACL query into two parts. It's now two
	  small and light SQL queries, instead of one big one that
	  overwhelmed databases
 188    142	  Stylistic cleanups for HasRight optimizations
 189    143	  Relationship transactions are recorded and displayed more
	  robustly
 190    144	  Bumping the version to 3.0.4pre1
 191    145	  Updated french translation from Blaise Thauvin
  13    146	  Bumping to 3.0.4RC1
 192    147	  Attachment display bug fix from autrijus tang
 193    148	  Bumping the version to 3.0.4RC2
 198    149	  ShowAttachments had a relative path which hurt extensions
 199    150	  README updates to indicate deprecated dependencies
 200    151	  Debugging framework cleanup
 201    152	  Bumping version to 3.0.4

http://www.bestpractical.com/rt – Trouble Ticketing. Free.
rt-announce mailing list
rt-announce@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-announce

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jesse Vincent wrote:

I’m pleased to announce the immediate availability of RT 3.0.4.

This version seems to have cleaned up all of the weird perlish utf8
problems I had on importing my rt2 database to rt3, but I’m still
getting one other error:

[Mon Jul 14 20:57:05 2003] [crit]: Failed to create user : Must specify
’Name’ attribute (/opt/rt3/lib/RT/User_Overlay.pm:595)
[Mon Jul 14 20:57:05 2003] [error]: Could not load create a user with
the email address ‘’ to add as a watcher for ticket 102
(/opt/rt3/lib/RT/Ticket_Overlay.pm:1438)

I assume RT3 is more picky about user-creation than RT2 was. How would
I go about munging my data so it doesn’t skip these? I’m fine with
making them some kind of generic “unknown” user or something like that
until I can massage the database…
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/FAvmUu+jZtP2Zf4RAt5GAJ9B3hJdkMRLYc1Yr0alQmd3YflpFACcC9QT
T0oPFdA1vLicP0VZ8stHYWg=
=lWae
-----END PGP SIGNATURE-----