Problem with Korean language emails

Hi,

One of our users is complaining that since upgrading to 3.2.0, they
cannot send or receive Korean language emails to RT. They can create a
ticket from the GUI and that works properly, but the emails are
corrupted.

Anyone any ideas how to fix it?

Using 3.2.0
Apache 1.3.29
MySQL 4.0.20
Perl 5.8.3
Solaris 9

Thanks

RikOn Tue, 2004-07-13 at 23:05, rt-users-request@lists.bestpractical.com wrote:

Send RT-Users mailing list submissions to
rt-users@lists.bestpractical.com

To subscribe or unsubscribe via the World Wide Web, visit
The rt-users Archives
or, via email, send a message with subject or body ‘help’ to
rt-users-request@lists.bestpractical.com

You can reach the person managing the list at
rt-users-owner@lists.bestpractical.com

When replying, please edit your Subject line so it is more specific
than “Re: Contents of RT-Users digest…”

Today’s Topics:

  1. Re: upgrade help please :slight_smile: (michael-list)
  2. Blank Comment (Leon)
  3. Re: Blank Comment (Bret Martin)
  4. Re: Blank Comment (Alex Vandiver)
  5. Problems with Updating Ticket via Jumbo (Derek Buttineau)
  6. Re: Blank Comment (Bret Martin)
  7. Re: Email History (Matthew Will)
  8. Re: Blank Comment (Jesse Vincent)
  9. Re: Email History (Jesse Vincent)
  10. dumpfile-to-rt-3.0 problem: parser: unterminated quotedstring
    (Joop van de Wege)
  11. Re: dumpfile-to-rt-3.0 problem: parser: unterminated
    quotedstring (Jesse Vincent)

Message: 1
Date: Wed, 14 Jul 2004 06:04:29 +1000
From: “michael-list” michael-list@i4u.com.au
Subject: Re: [rt-users] upgrade help please :slight_smile:
To: rt-users@lists.bestpractical.com
Message-ID: 015c01c46914$9b727b10$0200a8c0@family
Content-Type: text/plain; charset=“iso-8859-1”

thanks for pointing that out :slight_smile: its a sign have to get some sleep,

i just completed the uninstall of DBIx::SearchBuilder and sucesfully
installed the 0.94 version
still getting similar error, this is the new error that im getting,

thanks Jesse and Michael for the help :slight_smile:

  error:  Unsatisfied dependency chain in Joins Users_2 at

/usr/local/share/perl/5.8.4/DBIx/SearchBuilder/Handle.pm line 889.

  context:  ...

  code stack:

/usr/local/share/perl/5.8.4/DBIx/SearchBuilder/Handle.pm:889
/usr/local/share/perl/5.8.4/DBIx/SearchBuilder.pm:316
/usr/local/share/perl/5.8.4/DBIx/SearchBuilder.pm:109
/usr/local/share/perl/5.8.4/DBIx/SearchBuilder.pm:400
/opt/rt2/lib/RT/Tickets.pm:996
/opt/rt2/WebRT/html/Elements/MyRequests:11
/opt/rt2/WebRT/html/index.html:9
/opt/rt2/WebRT/html/autohandler:58

----- Original Message -----
From: “Michael S. Liebman” m-liebman@northwestern.edu
To: “michael-list” michael-list@i4u.com.au
Cc: “Jesse Vincent” jesse@bestpractical.com;
rt-users@lists.bestpractical.com
Sent: Wednesday, July 14, 2004 5:16 AM
Subject: Re: [rt-users] upgrade help please :slight_smile:

On Wed, Jul 14, 2004 at 05:13:08AM +1000, michael-list wrote:

what i tried was using cpanp i sucessfully uninstalled Apache::DBI then
installed Apache::DBI ver 0.94 that i manually downloaded from the
cpan.org,
after an apache restart still getting the same error

Jesse’s suggestion was to downgrade DBIx::SearchBuilder not Apache::DBI.

Michael

----- Original Message -----
From: “Jesse Vincent” jesse@bestpractical.com
To: “michael-list” michael-list@i4u.com.au
Cc: rt-users@lists.bestpractical.com
Sent: Wednesday, July 14, 2004 4:29 AM
Subject: Re: [rt-users] upgrade help please :slight_smile:

Try backing down to DBIx::SearchBuilder 0.97

Michael S. Liebman m-liebman@northwestern.edu
http://msl521.freeshell.org/
“I have vision and the rest of the world wears bifocals.”
-Paul Newman in “Butch Cassidy & the Sundance Kid”


Message: 2
Date: Tue, 13 Jul 2004 22:49:31 +0200
From: Leon rt@tux.datalink.co.za
Subject: [rt-users] Blank Comment
To: rt-users@lists.bestpractical.com
Message-ID: 40F44ADB.1030202@tux.datalink.co.za
Content-Type: text/plain; charset=us-ascii; format=flowed

Hi
If I open a existing ticket and click on Comment, then click on Home
without doing anything on the comment screen, RT saves a blank Comment.

Does any one else have this problem? I haven’t had this problem with
3.0.11. I’m not sure if it is a scrip yet. i checked mine, but couldn’t
see how it would be able to do this.

Leon


Message: 3
Date: Tue, 13 Jul 2004 16:58:26 -0400
From: Bret Martin bam@miranda.org
Subject: Re: [rt-users] Blank Comment
To: Leon rt@tux.datalink.co.za
Cc: rt-users@lists.bestpractical.com
Message-ID: 14404.1089752306@anasazi.miranda.org
Content-Type: text/plain; charset=us-ascii

On Tue, 13 Jul 2004 22:49:31 +0200 Leon wrote:

If I open a existing ticket and click on Comment, then click on Home
without doing anything on the comment screen, RT saves a blank Comment.

Does any one else have this problem? I haven’t had this problem with
3.0.11. I’m not sure if it is a scrip yet. i checked mine, but couldn’t
see how it would be able to do this.

I bet you’re using MySQL and your tables are MyISAM and not InnoDB.

In RT 3.2, when you load the update page, it looks like RT creates an
empty comment or reply and then rolls back the transaction. Since
MyISAM tables don’t support transactions, the blank comment/reply stays.

I didn’t trace this through in the code so I don’t know where it happens
– I figured it out my observing my MySQL query log when I noticed the
same thing on a test RT instance where I had set it up with MyISAM
tables.

–Bret


Message: 4
Date: Tue, 13 Jul 2004 17:08:47 -0400
From: Alex Vandiver alexmv@bestpractical.com
Subject: Re: [rt-users] Blank Comment
To: Bret Martin bam@miranda.org
Cc: rt-users@lists.bestpractical.com
Message-ID: 1089752927.10953.3.camel@zoq-fot-pik.mit.edu
Content-Type: text/plain

On Tue, 2004-07-13 at 16:58, Bret Martin wrote:

I bet you’re using MySQL and your tables are MyISAM and not InnoDB.
That’d be my guess, too.

I didn’t trace this through in the code so I don’t know where it happens
It happens when the “this message will be sent to” section is generated;
the most foolproof method is, as you noted, to fake a comment, find out
what happened, then roll it back.
The solution is to use a MySQL server that supports InnoDB tables.
Starting with RT 3.2.1, trying to install RT with a MySQL build that
doesn’t support InnoDB tables will give an error.

  • Alex


Networking – one letter away from not working


Message: 5
Date: Tue, 13 Jul 2004 16:40:51 -0400
From: Derek Buttineau derek@csolve.net
Subject: [rt-users] Problems with Updating Ticket via Jumbo
To: rt-users@lists.bestpractical.com
Message-ID: 40F448D3.1000506@csolve.net
Content-Type: text/plain; charset=us-ascii; format=flowed

Okay this is a bit odd of a problem…

First software:

Apache 2.0.50
mod_perl 1.99_14
RT 3.2.0

-Adding just a comment via Jumbo works fine, no issues, page returns
with a status message indicating what was done (as expected)

  • Changing the queue on a ticket + adding a comment works on both
    pieces, however no status message is returned, it just returns to the
    Jumbo screen
  • Changing the Owner on a ticket + adding a comment works for the change
    of ownership but the comment content is lost

I haven’t checked if any other combination causes issues, I will also
check a similar coniguration except using FastCGI in a short while.

Just thought I should mention it in case it’s a potential bug.


Regards,

Derek Buttineau
Internet Systems Developer
Compu-SOLVE Technologies Inc.
Compu-SOLVE Internet Services

705.725.1212 x255


Message: 6
Date: Tue, 13 Jul 2004 17:14:56 -0400
From: Bret Martin bam@miranda.org
Subject: Re: [rt-users] Blank Comment
To: Alex Vandiver alexmv@bestpractical.com
Cc: rt-users@lists.bestpractical.com
Message-ID: 14770.1089753296@anasazi.miranda.org
Content-Type: text/plain; charset=us-ascii

On Tue, 13 Jul 2004 17:08:47 EDT Alex Vandiver wrote:

The solution is to use a MySQL server that supports InnoDB tables.
Starting with RT 3.2.1, trying to install RT with a MySQL build that
doesn’t support InnoDB tables will give an error.

I don’t know if you care, but I noticed when installing RT 3.2.0 that
the stanza that creates the “sessions” table in schema.mysql doesn’t
have “TYPE=InnoDB;” at the end, but all the other CREATE TABLEs do have
it.

At first I wasn’t sure why that one table way MyISAM and the rest were
InnoDB – this was before I switched my MySQL configuration to have
InnoDB as the default table type.

Then again, maybe RT’s use of that table doesn’t require InnoDB
functionality. Seems like it would be nice to have the tables all of
the same type though.

–Bret


Message: 7
Date: Tue, 13 Jul 2004 17:27:20 -0400
From: Matthew Will mwill@spingen.com
Subject: Re: [rt-users] Email History
To: rt-users@lists.bestpractical.com
Message-ID: 40F453B8.4080308@spingen.com
Content-Type: text/plain; charset=us-ascii; format=flowed

Just as an update I have commented out line #266 in
lib/RT/Action/SendEmail.pm to disable it from recording outgoing mail
transactions to the database. If this has an adverse effect on anything
please let me know, although it seems to have done the trick.

Regards,

Matthew Will mwill@spingen.com

Matthew Will wrote:

I am curious to know if it is easily possible to disable the recording
of outgoing emails in a tickets history. Jesse has mentioned that this
will be an option that can be configured in 3.2.1, but it would be a
real convience if it’s a quick bit of commenting out some code, to be
able to do this now.

Regards,

Matthew Will mwill@spingen.com


The rt-users Archives

Be sure to check out the RT wiki at http://wiki.bestpractical.com


Message: 8
Date: Tue, 13 Jul 2004 17:47:59 -0400
From: Jesse Vincent jesse@bestpractical.com
Subject: Re: [rt-users] Blank Comment
To: Bret Martin bam@miranda.org
Cc: rt-users@lists.bestpractical.com
Message-ID: 20040713214759.GY13260@pallas.eruditorum.org
Content-Type: text/plain; charset=us-ascii

On Tue, Jul 13, 2004 at 05:14:56PM -0400, Bret Martin wrote:

On Tue, 13 Jul 2004 17:08:47 EDT Alex Vandiver wrote:

The solution is to use a MySQL server that supports InnoDB tables.
Starting with RT 3.2.1, trying to install RT with a MySQL build that
doesn’t support InnoDB tables will give an error.

I don’t know if you care, but I noticed when installing RT 3.2.0 that
the stanza that creates the “sessions” table in schema.mysql doesn’t
have “TYPE=InnoDB;” at the end, but all the other CREATE TABLEs do have
it.

The sessions table is really just there for Apache::Session. It doesn’t
need to be innodb.


Message: 9
Date: Tue, 13 Jul 2004 17:49:10 -0400
From: Jesse Vincent jesse@bestpractical.com
Subject: Re: [rt-users] Email History
To: Matthew Will mwill@spingen.com
Cc: rt-users@lists.bestpractical.com
Message-ID: 20040713214910.GZ13260@pallas.eruditorum.org
Content-Type: text/plain; charset=us-ascii

That should be fine. 3.2.1 makes that line conditional.

On Tue, Jul 13, 2004 at 05:27:20PM -0400, Matthew Will wrote:

Just as an update I have commented out line #266 in
lib/RT/Action/SendEmail.pm to disable it from recording outgoing mail
transactions to the database. If this has an adverse effect on anything
please let me know, although it seems to have done the trick.

Regards,

Matthew Will mwill@spingen.com

Matthew Will wrote:

I am curious to know if it is easily possible to disable the recording
of outgoing emails in a tickets history. Jesse has mentioned that this
will be an option that can be configured in 3.2.1, but it would be a
real convience if it’s a quick bit of commenting out some code, to be
able to do this now.

Regards,

Matthew Will mwill@spingen.com


The rt-users Archives

Be sure to check out the RT wiki at http://wiki.bestpractical.com


The rt-users Archives

Be sure to check out the RT wiki at http://wiki.bestpractical.com


Message: 10
Date: Tue, 13 Jul 2004 23:11:32 +0200
From: Joop van de Wege JoopvandeWege@mococo.nl
Subject: [rt-users] dumpfile-to-rt-3.0 problem: parser: unterminated
quotedstring
To: rt-users@lists.bestpractical.com
Message-ID: 20040713225637.9A6C.JOOPVANDEWEGE@mococo.nl
Content-Type: text/plain; charset=“US-ASCII”

I’ve detected the reason of the problem, but I don’t know how to
woraroud
it.
The cause is that the attachment is marked as base64-encoded while IT IS
NOT!
It was base64-encoded in the RT2 database, I checked that up with direct SQL
query.
But serialized version of the ticket in the exported form contains decoded
content of the attachment.
I can’t find decoding in rt-2.0-to-dumpfile script so it must be performed
somewhere in the RT library (probably $att->Content() do that???). So
dumpfile-to-rt-3.0 have to encode it back to base64 to be able to store it
to the database.

In this case the problem must be in this piece of code of the
rt-2.0-to-dumpfile script:

              my $att_param ( sort keys %{ $att->{_AccessibleCache} } )

{
if ($att_param eq ‘Content’) {
$att_ds->{$att_param} = $att->Content();

                     } else {

                            $att_ds->{$att_param} =

$att->_Value($att_param)
if (defined $att->_Value($att_param)
);
}

and actualy there is no need to decode attachment content if it is
base64-encoded?

Regards,

Alexei Barantsev
I’m having a similar problem moving data from RT2.0.13 to RT3.2.0 using
Oracle as a backend.
The same problem, data in RT2 is base64 encoded in the database, which
is regulated through the BinarySafeBlobs boolean in SearchBuilder. If
set to true it will store binaries in binary else it will base64 encode
them and store them in ASCII.
If you read through Attachment.pm in lib/RT there it will say that it
will decode base64 before returning it to the client app in this case
rt2-to-dumpfile which will store it decoded into the dumpfiles. There it
will also store that it is base64 encoded data which is not correct.
Further when this data is imported using dumpfile-to-rt3 I think
something else goes wrong

  • it should honor either the fact that the encoding is no longer base64
    thus ignoring the explicit encoding-type.
  • or maybe it shouldn’t use Import but Create in which case it may
    correctly figure out that it is binary and needs to be encoded.

Looking at some code it looks like there is something that might be
usable to both of us namely: RT::AlwaysUseBase64.
I’m going to investigate tomorrow if either BLOB’s in Oracle work or if
I can force base64 encoding which it already should do according to
SearchBuilder/Handle/Oracle.pm

Joop
PS:
Sorry for any mistake in logic, its getting late after quite a few
looongg days.

Richard Ellis wrote:

Hi,

One of our users is complaining that since upgrading to 3.2.0, they
cannot send or receive Korean language emails to RT. They can create a
ticket from the GUI and that works properly, but the emails are
corrupted.

Anyone any ideas how to fix it?
You should provide debug info.
Test email that fails(for example: in Mozilla Mail in outgoing folder
choose mail and click right button on content->view source->copy&send )
Mail logs.
RT logs with debug level:
wiki.bestpractical.com/?Debug