[rt-users] Problem with Korean language emails

Richard Ellis Richard.Ellis at Sun.COM
Wed Jul 14 07:07:14 EDT 2004


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

Rik
On Tue, 2004-07-13 at 23:05, rt-users-request at lists.bestpractical.com
wrote:
> Send RT-Users mailing list submissions to
> 	rt-users at lists.bestpractical.com
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
> or, via email, send a message with subject or body 'help' to
> 	rt-users-request at lists.bestpractical.com
> 
> You can reach the person managing the list at
> 	rt-users-owner at 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 :) (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 at i4u.com.au>
> Subject: Re: [rt-users] upgrade help please :)
> To: <rt-users at lists.bestpractical.com>
> Message-ID: <015c01c46914$9b727b10$0200a8c0 at family>
> Content-Type: text/plain;	charset="iso-8859-1"
> 
> thanks for pointing that out :) 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 :)
> 
> 
>       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 at northwestern.edu>
> To: "michael-list" <michael-list at i4u.com.au>
> Cc: "Jesse Vincent" <jesse at bestpractical.com>;
> <rt-users at lists.bestpractical.com>
> Sent: Wednesday, July 14, 2004 5:16 AM
> Subject: Re: [rt-users] upgrade help please :)
> 
> 
> > 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 at bestpractical.com>
> > > To: "michael-list" <michael-list at i4u.com.au>
> > > Cc: <rt-users at lists.bestpractical.com>
> > > Sent: Wednesday, July 14, 2004 4:29 AM
> > > Subject: Re: [rt-users] upgrade help please :)
> > >
> > >
> > > > Try backing down to DBIx::SearchBuilder 0.97
> > -- 
> > Michael S. Liebman                      m-liebman at 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 at tux.datalink.co.za>
> Subject: [rt-users] Blank Comment
> To: rt-users at lists.bestpractical.com
> Message-ID: <40F44ADB.1030202 at 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 at miranda.org>
> Subject: Re: [rt-users] Blank Comment 
> To: Leon <rt at tux.datalink.co.za>
> Cc: rt-users at lists.bestpractical.com
> Message-ID: <14404.1089752306 at 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 at bestpractical.com>
> Subject: Re: [rt-users] Blank Comment
> To: Bret Martin <bam at miranda.org>
> Cc: rt-users at lists.bestpractical.com
> Message-ID: <1089752927.10953.3.camel at 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 at csolve.net>
> Subject: [rt-users] Problems with Updating Ticket via Jumbo
> To: rt-users at lists.bestpractical.com
> Message-ID: <40F448D3.1000506 at 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 at miranda.org>
> Subject: Re: [rt-users] Blank Comment 
> To: Alex Vandiver <alexmv at bestpractical.com>
> Cc: rt-users at lists.bestpractical.com
> Message-ID: <14770.1089753296 at 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 at spingen.com>
> Subject: Re: [rt-users] Email History
> To: rt-users at lists.bestpractical.com
> Message-ID: <40F453B8.4080308 at 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 at 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 at spingen.com>
> > _______________________________________________
> > http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
> > 
> > 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 at bestpractical.com>
> Subject: Re: [rt-users] Blank Comment
> To: Bret Martin <bam at miranda.org>
> Cc: rt-users at lists.bestpractical.com
> Message-ID: <20040713214759.GY13260 at 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 at bestpractical.com>
> Subject: Re: [rt-users] Email History
> To: Matthew Will <mwill at spingen.com>
> Cc: rt-users at lists.bestpractical.com
> Message-ID: <20040713214910.GZ13260 at 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 at 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 at spingen.com>
> > >_______________________________________________
> > >http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
> > >
> > >Be sure to check out the RT wiki at http://wiki.bestpractical.com
> > 
> > _______________________________________________
> > http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
> > 
> > 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 at mococo.nl>
> Subject: [rt-users] dumpfile-to-rt-3.0 problem: parser: unterminated
> 	quotedstring
> To: rt-users at lists.bestpractical.com
> Message-ID: <20040713225637.9A6C.JOOPVANDEWEGE at 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.




More information about the rt-users mailing list