[rt-users] Problem with Korean language emails
Ruslan U. Zakirov
cubic at acronis.ru
Wed Jul 14 07:18:01 EDT 2004
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
>
> 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.
>
>
> _______________________________________________
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
>
> Be sure to check out the RT wiki at http://wiki.bestpractical.com
More information about the rt-users
mailing list