RT 3.0.1 is now available

RT 3.0.1 is primarily a bug-fix release. A number of issues have been
corrected, primarily several UTF-8 related issues, as well as an issue
that could cause corruption of binary attachments.

This release is now available at:

http://fsck.com/pub/rt/release/rt-3-0-1.tar.gz

Changelog annotations are below. For more detail, consult aegis at

http://fsck.com/aegis/aegis.cgi?file@proj_menu+project@rt.3.0

  33     20	  A tiny bit of extra data passing for some callbacks
  35     21	  New czech translation
  37     22	  Updated dependencies
  36     23	  Updated Spanish translation
  38     24	  Updates for RT RPC interface from AMS
  39     25	  Many users should be able to have a blank address; new test suite to ensure this
  50     26	  Integrating rafael's failing UTF-8 test suite and proposed fix from autrijus
  51     27	  Changing address used in examples to not send mail to author
  53     29	  Added preliminary left to right hebrew translation
  55     30	  #2365 Removing outdated Mason setup parameter
  56     31	  Testing fixes for mail authentication/authorization
  58     33	  Better binary attachment handling fix from autrijus
  59     34	  Bumping to RT 3.0.1pre2
  60     35	  SMTP and I18N fixes from autrijus tang. Updated chinese translations
  61     36	  New speedycgi support from vivek khera
  62     37	  Bumping to version 3.0.1

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

Ok. It looks lik a couple issues crept into the 3.0.1 release.

My flight to the UK is about to board, but I’ll see about getting a
point release out once I find network in the UK on wednesday.

Jesse VincentOn Wed, Apr 16, 2003 at 12:00:10AM +0200, Jeroen Ruigrok/asmodai wrote:

-On [20030415 18:34], Jesse Vincent (jesse@bestpractical.com) wrote:

RT 3.0.1 is primarily a bug-fix release. A number of issues have been
corrected, primarily several UTF-8 related issues, as well as an issue
that could cause corruption of binary attachments.

Using up to date perl modules, except SearchBuilder, since I need to
benchmark the old one first (0.80 though), and a compliant Storable
(current one won’t build), I get this under perl 5.8.0:

[Tue Apr 15 23:57:05 2003] [warn] FastCGI: server
"/usr/local/rt/bin/mason_handler.fcgi" restarted (pid 57896)
Insecure dependency in require while running setgid at
/usr/local/rt3/lib/RT/I18N.pm line 82.
Compilation failed in require at /usr/local/rt/bin/mason_handler.fcgi
line 28.
[Tue Apr 15 23:57:08 2003] [warn] FastCGI: server
"/usr/local/rt/bin/mason_handler.fcgi" (pid 57896) terminated by calling
exit with status ‘255’

 78 sub Init {
 79     # Load language-specific functions
 80     foreach my $language ( glob(substr(__FILE__, 0, -3) . "/*.pm")) {
 81         if ($language =~ /\b([-\w.\/\\]+)$/) {
 82             require $language;
 83         }

Hope this helps,


Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai / a capoeirista
PGP fingerprint: 2D92 980E 45FE 2C28 9DB7 9D88 97E6 839B 2EAC 625B
http://www.tendra.org/ | http://www.in-nomine.org/~asmodai/diary/
Only the wisest and the stupidest of men never change…

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

Hi Jesse,— Jesse Vincent jesse@bestpractical.com wrote:

RT 3.0.1 is primarily a bug-fix release. A number of issues have been
corrected, primarily several UTF-8 related issues, as well as an issue
that could cause corruption of binary attachments.

After upgrading from 3.0.1pre2:

the incoming e-mail with
charset=“iso-8859-1” and a single non-ASCII character in it:
regardless of the ticket number present or not in the subject line,
the new ticket is created with empty Requestor, body and subject.

I’ll try and dig into the problem while you’re on the road.

Cheers,
Stan

the incoming e-mail with
charset=“iso-8859-1” and a single non-ASCII character in it:
regardless of the ticket number present or not in the subject line,
the new ticket is created with empty Requestor, body and subject.

The whole mess is around the line 26 in html/autohandler.
Before Change 60 it was:
Encode::utf8_on($ARGS{$}) foreach (keys %ARGS);

After that it is:
$ARGS{$} = Encode::decode_utf8($ARGS{$}) foreach (keys %ARGS);

After the change, the iso-8859-1 e-mail messages are screwed as described above.
UTF-8 e-mail messages are handled fine.

With this line reverted to the old value, not everything is fine:
When the iso-8859-1 e-mail comes,
each accent or umlaut character is stored in the database as 4 bytes,
and is diasplayed in the web interface as two meaningless Unicode symbols.
But the notification e-mail sent to AdminCC contains correctly written UTF-8 text.

With this line commented out, not everything’s fine either:
The database contains correctly encoded UTF-8 text,
but the e-mail to AdminCC has utf-8 in the header, but the body in fact
is encoded as Latin1.

I hope this helps to track the problem down.

Regards,
Stan

On a related note, I see this happening to templates I try to save
under 3.0.1pre2 and 3.0.1 as well - the web interface reports ‘the new
value has been set’, but the template is not saved if umlauts are
entered. I checked the database, and the template is not stored. If I
change an existing template (without umlauts) to contain umlauts, the
old template is deleted (in the database).

This is with MySQL 3.23.54a and 4.0.10

Regards,
Harald Wagener

Harald Wagener * FCB/Wilkens * An der Alster 42 * 20099 Hamburg

the incoming e-mail with
charset=“iso-8859-1” and a single non-ASCII character in it:
regardless of the ticket number present or not in the subject line,
the new ticket is created with empty Requestor, body and subject.

The whole mess is around the line 26 in html/autohandler.

Hi all,

perhaps it would be easier to handle the international charsets, if
the charset conversion to UTF8 would happen within rt-mailgate, before
POSTing to the web interface.

Stan