Re: [rt-users] RT Reminders - Not sending email
That doesn't seem to be a complete log. More lines should follow. Is that not the case? On 9 August 2014 02:14, globo michael.obr...@globoforce.com wrote: I am unable to get RT to send email reminders using the RT Reminder function. Any help much appricated *RT Version *= RT 4.0.17 *Issue* : unable to get emails to send using the RT Reminders *Log * [Fri Aug 8 15:38:02 2014] [debug]: Converting 'utf-8' to 'utf-8' for text/plain - [domain.com #28979] test1 (/opt/rt4/bin/../lib/RT/I18N.pm:244) [Fri Aug 8 15:38:02 2014] [debug]: Calling SetRecipientDigests for transaction RT::Transaction=HASH(0x765c418), id 408835 (/opt/rt4/bin/../lib/RT/Action/SendEmail.pm:629) [Fri Aug 8 15:38:02 2014] [debug]: Working on mailfield To; recipients are (/opt/rt4/bin/../lib/RT/Action/SendEmail.pm:645) [Fri Aug 8 15:38:02 2014] [debug]: Subject: [domain.com #28979] test1 -- View this message in context: http://requesttracker.8502.n7.nabble.com/RT-Reminders-Not-sending-email-tp58287.html Sent from the Request Tracker - User mailing list archive at Nabble.com. -- RT Training - Boston, September 9-10 http://bestpractical.com/training -- RT Training - Boston, September 9-10 http://bestpractical.com/training
Re: [rt-users] RT Reminders - Not sending email
On Fri, Aug 08, 2014 at 09:14:41AM -0700, globo wrote: I am unable to get RT to send email reminders using the RT Reminder function. Any help much appricated *RT Version *= RT 4.0.17 *Issue* : unable to get emails to send using the RT Reminders How are you sending mail about Reminders. RT core doesn't have any job to send mail about them. Your log is also truncated and lacking details. -kevin *Log * [Fri Aug 8 15:38:02 2014] [debug]: Converting 'utf-8' to 'utf-8' for text/plain - [domain.com #28979] test1 (/opt/rt4/bin/../lib/RT/I18N.pm:244) [Fri Aug 8 15:38:02 2014] [debug]: Calling SetRecipientDigests for transaction RT::Transaction=HASH(0x765c418), id 408835 (/opt/rt4/bin/../lib/RT/Action/SendEmail.pm:629) [Fri Aug 8 15:38:02 2014] [debug]: Working on mailfield To; recipients are (/opt/rt4/bin/../lib/RT/Action/SendEmail.pm:645) [Fri Aug 8 15:38:02 2014] [debug]: Subject: [domain.com #28979] test1 pgpbZv_pOyPeY.pgp Description: PGP signature -- RT Training - Boston, September 9-10 http://bestpractical.com/training
Re: [rt-users] Some users being forced to reauthenticate more often than others
On Wed, Aug 06, 2014 at 04:34:20PM -0400, Jeff Blaine wrote: RT 4.2.5 We're trying to track down an issue where some users are being forced to reauthenticate to RT 3-4 times per day while others aren't. This RT instance is using the builtin authentication targeting the 'rt4' database. Our session-cleaning cron job is as follows 0 * * * * /apps/rt4/sbin/rt-clean-sessions --older 2D Any suggested paths to start down would be welcome. RT's login cookies are per-browser session. Are the users who get logged out the type of user who close all their browser windows at lunchtime or otherwise would cause that cookie to be expired? You can also have your session cleaner run in debug and look at the logs. -kevin pgpbBWXW8o2xR.pgp Description: PGP signature -- RT Training - Boston, September 9-10 http://bestpractical.com/training
Re: [rt-users] RT-Mailgate timeout error after upgrade to 4.2.6
On Wed, Aug 06, 2014 at 09:44:40PM +, Richards, Matthew E ERDC-RDE-CERL-IL wrote: If you're going to the localhost, I'm not actually sure why you're involving SSL, but that's a separate issue. Actually, that was the issue. You're right, there's no need to use SSL with localhost. We have a rewrite from 80 to 443 for all interfaces and it always forces us to use https. I guess we could have created a non-SSL site just for localhost. The DoD has its own root CA that we added in a ca_file, but I think it's very slow and was causing the timeouts. I changed the rt-mailgate get_useragent to $ua- ssl_opts(SSL_verify_mode = 'SSL_VERIFY_NONE'); and that solved the issue. It's a temporary fix until we create a locahost:80 binding. I don't like maintaining custom source. Thanks for all the help. If you don't want to verify, why not just use the flag? $ ./bin/rt-mailgate --help | grep verify --ca-file or --no-verify-ssl, below. authority that should be used to verify the website's SSL certificate. preferentially use this option over --no-verify-ssl, as it will --no-verify-ssl -kevin pgpEGC686EGKR.pgp Description: PGP signature -- RT Training - Boston, September 9-10 http://bestpractical.com/training
Re: [rt-users] Change ticket subject before first outgoing correspondence.
On Thu, Aug 07, 2014 at 02:00:01PM -0400, Michael Mol wrote:
* Scrip re-ordering appears to be a feature of the 4.2 line of RT. I'm
running the vendor packages of RT 4 on Ubuntu 14.04.
Nope. On RT 4.0, which is what I assume you mean by vendor packages RT
4 on Ubuntu 14.04 you order scrips by their descriptions. Typically
this is done by literally numbering scrips that will run in the same
condition.
* I looked into upgrading, but I did not find any repositories making
backported packages available to 14.04. Pity; I selected 14.04 so I
wouldn't have to override the system as often.
Debian has 4.2 packages available in testing, encouraging Ubuntu to
take upgrades would be helpful.
* Even though I can't reorder scrips, I can create disable global
scrips and create local scrips with the same name, resulting in a
higher ID number (and theoretically later execution). However, this
has no apparent effect, regardless of whether I run the overriding
Notify scrips in the TransactionCreate or TransactionBatch stages.
ID number has nothing to do with ordering.
I'm beginning to wonder if I need to set something beyond just the
ticket subject in my scrip. The scrip doing the work in question will
look familiar:
My last option appears to be to write a template that duplicates the
above logic in the template itself, which feels dirty, and looks
worse...
You still haven't said what the Scrip is that isn't firing, both Alex
and I assumed it was your Autoreply to Requestors because you were
unclear.
I've certainly modified a subject in a Scrip and then had an Autoreply
fire with the correct subject by using a TransactionBatch scrip.
Keep in mind, if you make all your Notify scrips TransactionBatch,
they will no longer show up in the Preview Scrips box.
I've seen your rewritten template, but a Notify scrip running in the
transaction batch stage which has merely
Subject: { $Ticket-Subject }
should be more than sufficient, assuming it runs after your Subject
modification scrip, preferably in a TransactionBatch scrip on the same
Condition.
-kevin
pgpGQU2mBzSSJ.pgp
Description: PGP signature
--
RT Training - Boston, September 9-10
http://bestpractical.com/training
Re: [rt-users] Unprivileged users - Edit ticket/Sign up as CC
On Wed, Aug 06, 2014 at 08:51:06PM +, Cena, Stephen (ext. 300) wrote: Kevin - What I mean is there are three check boxes: Everyone, Privileged, and Unprivileged. There are no checks in any box. You're conflating the state of a user with permissions granted to groups of users. Right now, my single Unprivileged user creates a ticket, but is only abble to Reply/Comment and that's all. The only updates available to Self Service users are those available on the Update page, which is available both by clicking Reply or by clicking on the title of The Basics box. As suggested by others in the thread, if your users need to modify dates and users on tickets, they need the Privileged UI or you need to extend the SelfService UI. -kevin pgpm_Eo44G3WQ.pgp Description: PGP signature -- RT Training - Boston, September 9-10 http://bestpractical.com/training
Re: [rt-users] RT Reminders - Not sending email
Hi Kevin Alex, Please see the full log === Precedence: bulk X-RT-Loop-Prevention: domain.com RT-Ticket: domain.com #28962 Managed-BY: RT 4.0.17 (http://www.bestpractical.com/rt/) RT-Originator: jon@domain.com MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-T[Fri Aug 8 10:19:37 2014] [debug]: You've enabled GraphViz, but we couldn't load the module: Can't locate GraphViz.pm in @INC (@INC contains: /opt/rt4/bin/../local/lib /opt/rt4/ bin/../lib /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at /opt/rt4/bin/../lib/RT/ Config.pm line 552. (/opt/rt4/bin/../lib/RT/Config.pm:553) [Fri Aug 8 10:19:37 2014] [debug]: RT's GnuPG libraries couldn't successfully read your configured GnuPG home directory (/opt/rt4/var/data/gpg). PGP support has been disabled (/ opt/rt4/bin/../lib/RT/Config.pm:589) [Fri Aug 8 10:19:37 2014] [debug]: The RTAddressRegexp option is not set in the config. Not setting this option results in additional SQL queries to check whether each address b elongs to RT or not. It is especially important to set this option if RT recieves emails on addresses that are not in the database or config. (/opt/rt4/bin/../lib/RT/Config.pm:44 8) [Fri Aug 8 10:19:37 2014] [debug]: Converting 'utf-8' to 'utf-8' for text/plain - [domain.com #28962] test (/opt/rt4/bin/../lib/RT/I18N.pm:244) [Fri Aug 8 10:19:37 2014] [debug]: Calling SetRecipientDigests for transaction RT::Transaction=HASH(0x54c05c8), id 408604 (/opt/rt4/bin/../lib/RT/Action/SendEmail.pm:629) [Fri Aug 8 10:19:37 2014] [debug]: Working on mailfield To; recipients are (/opt/rt4/bin/../lib/RT/Action/SendEmail.pm:645) [Fri Aug 8 10:19:37 2014] [debug]: Subject: [domain.com #28962] test From: Jon Doe via RT helpd...@domain.com Reply-To: helpd...@domain.com References: rt-ticket-28...@domain.com Message-ID: rt-4.0.17-7672-1407493177-786.28962-...@domain.com Precedence: bulk X-RT-Loop-Prevention: domain.com RT-Ticket: domain.com #28962 Managed-BY: RT 4.0.17 (http://www.bestpractical.com/rt/) RT-Originator: jon@domain.com MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 X-RT-Original-Encoding: utf-8 (/opt/rt4/bin/../lib/RT/Action/SendEmail.pm:652) [Fri Aug 8 10:19:37 2014] [debug]: Removing deferred recipients from To: line (/opt/rt4/bin/../lib/RT/Action/SendEmail.pm:675) [Fri Aug 8 10:19:37 2014] [debug]: Setting deferred recipients for attribute creation (/opt/rt4/bin/../lib/RT/Action/SendEmail.pm:684) [Fri Aug 8 10:19:37 2014] [debug]: Working on mailfield Cc; recipients are (/opt/rt4/bin/../lib/RT/Action/SendEmail.pm:645) [Fri Aug 8 10:19:37 2014] [debug]: Subject: [domain.com #28962] test From: Jon Doe via RT helpd...@domain.com Reply-To: helpd...@domain.com References: rt-ticket-28...@domain.com Message-ID: rt-4.0.17-7672-1407493177-786.28962-...@domain.com Precedence: bulk X-RT-Loop-Prevention: domain.com RT-Ticket: domain.com #28962 Managed-BY: RT 4.0.17 (http://www.bestpractical.com/rt/) RT-Originator: jon@domain.com MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 X-RT-Original-Encoding: utf-8 (/opt/rt4/bin/../lib/RT/Action/SendEmail.pm:652) [Fri Aug 8 10:19:37 2014] [debug]: Removing deferred recipients from Cc: line (/opt/rt4/bin/../lib/RT/Action/SendEmail.pm:675) [Fri Aug 8 10:19:37 2014] [debug]: Setting deferred recipients for attribute creation (/opt/rt4/bin/../lib/RT/Action/SendEmail.pm:684) [Fri Aug 8 10:19:37 2014] [debug]: Working on mailfield Bcc; recipients are (/opt/rt4/bin/../lib/RT/Action/SendEmail.pm:645) [Fri Aug 8 10:19:37 2014] [debug]: Subject: [domain.com #28962] test From: Jon Doe via RT helpd...@domain.com Reply-To: helpd...@domain.com References: rt-ticket-28...@domain.com Message-ID: rt-4.0.17-7672-1407493177-786.28962-...@domain.com Precedence: bulk X-RT-Loop-Prevention: domain.com RT-Ticket: domain.com #28962 Managed-BY: RT 4.0.17 (http://www.bestpractical.com/rt/) RT-Originator: jon@domain.com MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 X-RT-Original-Encoding: utf-8 (/opt/rt4/bin/../lib/RT/Action/SendEmail.pm:652) [Fri Aug 8 10:19:37 2014] [debug]: Removing deferred recipients from Bcc: line (/opt/rt4/bin/../lib/RT/Action/SendEmail.pm:675) [Fri Aug 8 10:19:37 2014] [debug]: Setting deferred recipients for attribute creation (/opt/rt4/bin/../lib/RT/Action/SendEmail.pm:684) [Fri Aug 8 10:19:37 2014] [debug]: No recipients found for deferred delivery on transaction #408604 (/opt/rt4/bin/../lib/RT/Action/SendEmail.pm:697) [Fri Aug 8 10:19:37 2014] [info]: rt-4.0.17-7672-1407493177-786.28962-...@domain.com #28962/408604 - Scrip #rule (/opt/rt4/bin/../lib/RT/Action/SendEmail.pm:285) [Fri Aug 8 10:19:37 2014] [info]: rt-4.0.17-7672-1407493177-786.28962-...@domain.com No recipients found. Not sending.
Re: [rt-users] Change ticket subject before first outgoing correspondence.
On Mon, Aug 11, 2014 at 11:09 AM, Kevin Falcone
falc...@bestpractical.com wrote:
On Thu, Aug 07, 2014 at 02:00:01PM -0400, Michael Mol wrote:
* Scrip re-ordering appears to be a feature of the 4.2 line of RT. I'm
running the vendor packages of RT 4 on Ubuntu 14.04.
Nope. On RT 4.0, which is what I assume you mean by vendor packages RT
4 on Ubuntu 14.04 you order scrips by their descriptions. Typically
this is done by literally numbering scrips that will run in the same
condition.
Oh, that's good to know! I searched for at least an hour trying to
find that precise piece of information.
* I looked into upgrading, but I did not find any repositories making
backported packages available to 14.04. Pity; I selected 14.04 so I
wouldn't have to override the system as often.
Debian has 4.2 packages available in testing, encouraging Ubuntu to
take upgrades would be helpful.
I don't think it's likely for 14.04, which is an LTS. If 4.2 is in
Debian/testing, then it should show up in Ubuntu 14.10, at which point
a backports repository traditionally appears. So I'd guess that RT 4.2
will become available to Ubuntu 14.04 users in a few months.
* Even though I can't reorder scrips, I can create disable global
scrips and create local scrips with the same name, resulting in a
higher ID number (and theoretically later execution). However, this
has no apparent effect, regardless of whether I run the overriding
Notify scrips in the TransactionCreate or TransactionBatch stages.
ID number has nothing to do with ordering.
I'm beginning to wonder if I need to set something beyond just the
ticket subject in my scrip. The scrip doing the work in question will
look familiar:
My last option appears to be to write a template that duplicates the
above logic in the template itself, which feels dirty, and looks
worse...
You still haven't said what the Scrip is that isn't firing, both Alex
and I assumed it was your Autoreply to Requestors because you were
unclear.
Custom condition, matching the ticket subject and queue name. (The
latter being redundant, since it's a queue-specific scrip.)
The scrip *does* fire, as evidenced by the ticket's subject changing.
However, the AdminCC emails go out before the scrip fires. This is
true even though I have all of the Notify scrips in the
TransactionBatch stage, even though I have this scrip in the
TransactionCreate stage.
Here: (The queue name has been replaced with somequeuename)
### Begin snippet for custom condition
return 0 unless $self-TransactionObj-Type eq Create;
return 0 unless $self-TicketObj-QueueObj-Name eq somequeuename;
return 1 if $self-TicketObj-Subject =~ HP Insight Management Agents
Trap Alarm;
return 1 if $self-TicketObj-Subject =~ HP Agent Trap Alert;
return 0;
### End snippet for custom condition
### Begin snippet for custom action preparation code
# Find the message from transactionobj-content
# Set the subject to the message by using ticketobj-SetSubject
my $body = $self-TransactionObj-Content;
my @lines = split(m/\n/, $body);
my $trapID = $lines[0];
my $message = $lines[2];
$self-TicketObj-SetSubject($trapID -- $message);
### End snippet for custom action preparation code
### Begin snippet for custom action cleanup code
# No cleanup necessary; all the work was done in the prep stage.
return 1;
### End snippet for custom action cleanup code
I've certainly modified a subject in a Scrip and then had an Autoreply
fire with the correct subject by using a TransactionBatch scrip.
Keep in mind, if you make all your Notify scrips TransactionBatch,
they will no longer show up in the Preview Scrips box.
I've seen your rewritten template, but a Notify scrip running in the
transaction batch stage which has merely
Subject: { $Ticket-Subject }
should be more than sufficient, assuming it runs after your Subject
modification scrip, preferably in a TransactionBatch scrip on the same
Condition.
Interesting. Where does the subject come from, if not
$Ticket-Subject? (I guess I could just look at the source code for
that.)
--
:wq
--
RT Training - Boston, September 9-10
http://bestpractical.com/training
Re: [rt-users] Change ticket subject before first outgoing correspondence.
I have a question related to this thread.
Kevin you mention that scrips fire in order of name so does that mean when the
order is set for a queue this is ignored? If so what is the purpose of the
Move Up, Down for the scrips on a queue?
Thanks
Sorry for butting in.
Bryon Baker
Network Operations Manager
Copesan - Specialists in Pest Solutions
800-267-3726 . 262-783-6261 ext. 2296
bba...@copesan.com
www.copesan.com
Servicing North America with Local Care
-Original Message-
From: rt-users [mailto:rt-users-boun...@lists.bestpractical.com] On Behalf Of
Kevin Falcone
Sent: Monday, August 11, 2014 10:09 AM
To: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Change ticket subject before first outgoing
correspondence.
On Thu, Aug 07, 2014 at 02:00:01PM -0400, Michael Mol wrote:
* Scrip re-ordering appears to be a feature of the 4.2 line of RT. I'm
running the vendor packages of RT 4 on Ubuntu 14.04.
Nope. On RT 4.0, which is what I assume you mean by vendor packages RT
4 on Ubuntu 14.04 you order scrips by their descriptions. Typically this is
done by literally numbering scrips that will run in the same condition.
* I looked into upgrading, but I did not find any repositories making
backported packages available to 14.04. Pity; I selected 14.04 so I
wouldn't have to override the system as often.
Debian has 4.2 packages available in testing, encouraging Ubuntu to take
upgrades would be helpful.
* Even though I can't reorder scrips, I can create disable global
scrips and create local scrips with the same name, resulting in a
higher ID number (and theoretically later execution). However, this
has no apparent effect, regardless of whether I run the overriding
Notify scrips in the TransactionCreate or TransactionBatch stages.
ID number has nothing to do with ordering.
I'm beginning to wonder if I need to set something beyond just the
ticket subject in my scrip. The scrip doing the work in question will
look familiar:
My last option appears to be to write a template that duplicates the
above logic in the template itself, which feels dirty, and looks
worse...
You still haven't said what the Scrip is that isn't firing, both Alex and I
assumed it was your Autoreply to Requestors because you were unclear.
I've certainly modified a subject in a Scrip and then had an Autoreply fire
with the correct subject by using a TransactionBatch scrip.
Keep in mind, if you make all your Notify scrips TransactionBatch, they will no
longer show up in the Preview Scrips box.
I've seen your rewritten template, but a Notify scrip running in the
transaction batch stage which has merely
Subject: { $Ticket-Subject }
should be more than sufficient, assuming it runs after your Subject
modification scrip, preferably in a TransactionBatch scrip on the same
Condition.
-kevin
--
RT Training - Boston, September 9-10
http://bestpractical.com/training
Re: [rt-users] 'content matches' and 'content doesn't match' give same results
On 08/10/2014 07:53 PM, Jeff Blaine wrote: [ I ran a search with StatementLogging enabled and this ] [ is the sql statement with content not like 'foo.com' ] [ and content like 'foo.com', they are the same. ] [ --Thanks for that, Joop! ] Alex, to be clear, these queries below were done via the search form. I am only quoting the SearchBuilder terms for simplicity. The form stated: [ Content ] [ matches ] __foo.com___ And [ Content ] [ doesn't match ] __foo.com___ and I clicked search to get the same 3 tickets as results for both. I can't see how, in some way or another, this is not a bug. Content doesn't match indeed uses the same codepath as content does match. The problem is that not all of the FTS backends support NOT MATCH -- and for those that do, it likely doesn't do what you expect. I can guarantee that for any particular phrase, there exists one transaction on the ticket which does not contain that phrase -- thus always matching all tickets. Can you explain your use case a bit? I expect that you meant it as exclude tickets which do contain? I expect we should, at least in the short term, document that CONTENT NOT LIKE is not supported, and make it return the empty set. - Alex -- RT Training - Boston, September 9-10 http://bestpractical.com/training
Re: [rt-users] 'content matches' and 'content doesn't match' give same results
Can you explain your use case a bit? I expect that you meant it as exclude tickets which do contain? That's correct. -- Jeff Blaine kickflop.net PGP/GnuPG Key ID: 0x0C8EDD02 -- RT Training - Boston, September 9-10 http://bestpractical.com/training
Re: [rt-users] Change ticket subject before first outgoing correspondence.
On Mon, Aug 11, 2014 at 1:21 PM, Bryon Baker bba...@copesan.com wrote: I have a question related to this thread. Kevin you mention that scrips fire in order of name so does that mean when the order is set for a queue this is ignored? If so what is the purpose of the Move Up, Down for the scrips on a queue? Thanks Sorry for butting in. No; scrip-order-by-name does not apply to RT 4.2. If you have Move Up, Down buttons, you don't need to worry about order-by-name. I'm dealing with an older version of RT, which is why the order-by-name stuff came up. -- :wq -- RT Training - Boston, September 9-10 http://bestpractical.com/training
Re: [rt-users] 'content matches' and 'content doesn't match' give same results
On 11-8-2014 19:45, Alex Vandiver wrote: On 08/10/2014 07:53 PM, Jeff Blaine wrote: [ I ran a search with StatementLogging enabled and this ] [ is the sql statement with content not like 'foo.com' ] [ and content like 'foo.com', they are the same. ] [ --Thanks for that, Joop! ] Alex, to be clear, these queries below were done via the search form. I am only quoting the SearchBuilder terms for simplicity. The form stated: [ Content ] [ matches ] __foo.com___ And [ Content ] [ doesn't match ] __foo.com___ and I clicked search to get the same 3 tickets as results for both. I can't see how, in some way or another, this is not a bug. Content doesn't match indeed uses the same codepath as content does match. The problem is that not all of the FTS backends support NOT MATCH -- and for those that do, it likely doesn't do what you expect. I can guarantee that for any particular phrase, there exists one transaction on the ticket which does not contain that phrase -- thus always matching all tickets. Running the query from the statementlog and modifying as described (adding a not) does what it needs todo, exclude all tickets that have that phrase in it. This is using Pg as a backend. Oracle works too. Mysql I don't know because I don't use it for RT. Joop -- RT Training - Boston, September 9-10 http://bestpractical.com/training
[rt-users] Assets and CSV export. Not all default fields displaying data
Hello, We have started using Assets 1.01 for RT. One of the things I found is that when I do a search and then attempt to export to csv I don't get all of the data. Before doing the export the onscreen data is looking correct. For example it has a Name, SN, Tag, Description, Heldby and Owner . . . . The exported file does include all of the headings but not all of the data. For example it does not show data for Name, Description, Heldby but does include some data like Sn, Tag, Owner. Of the fields that are not showing data, most of them (if not all of them) are non-custom fields (default fields). But some data from the non-custom fields (like owner) does show up. . I have checked the file in both Excel and Notepad. It doesn't appear to be affected by number of rows, or search results. Is anyone else seen this problem Thanks, Armin PS I did report this prior to emailing here, but have since read something that says email here first. Sorry. -- RT Training - Boston, September 9-10 http://bestpractical.com/training
[rt-users] Data corruption with DBD::Pg 3.3.0
On Wed, Aug 06, 2014 at 12:43:35PM -0400, Alex Vandiver wrote: On 08/06/2014 12:38 PM, saxmad wrote: I'm on RT release 4.0.7 (form the Debian backports repo), with no imminent upgrade in mind, so that should be fine. No, it shouldn't be; re-read my message. DBD::Pg 3.3.0 breaks _all_ versions of RT. You _will_ have data corruption if you install DBD::Pg on your version of RT. This is a pretty serious issue. I don't see any sign of a bug against DBD::Pg in the CPAN bugtracker, and Debian now has 3.3.0 in unstable and testing. Could you say a bit more about the problem and what plans there are to fix/workaround it for RT? Forcing a lower version of DBD::Pg isn't a practical option in a packaged environment like Debian. Cheers, Domninic. -- Dominic Hargreaves, Systems Development and Support Section IT Services, University of Oxford signature.asc Description: Digital signature -- RT Training - Boston, September 9-10 http://bestpractical.com/training
Re: [rt-users] Data corruption with DBD::Pg 3.3.0
On 08/11/2014 05:23 PM, Dominic Hargreaves wrote: I don't see any sign of a bug against DBD::Pg in the CPAN bugtracker, and Debian now has 3.3.0 in unstable and testing. The bug isn't DBD::Pg's fault -- hence why there's nothing we've reported -- but rather a case of it becoming _more_ correct, and there being lurking code in the bowels of DBIx::SearchBuilder that was incorrect, and now interacts poorly. Specifically: https://github.com/bestpractical/dbix-searchbuilder/blob/master/lib/DBIx/SearchBuilder/Handle.pm#L577-L579 ..which takes characters that we're trying to insert into the database and encodes them in UTF-8[1] -- which is then _double_ encoded when DBD::Pg 3.3.0 realizes that the database column is textual. Previous to 3.3.0, it accepted bytes and inserted bytes, which we would later read out as characters. Now, it accepts bytes and attempts to insert them as character codepoints, so that the data round-trips and we get the same character codepoints out. Which is more correct, as 3.2.1 relied on the UTF-8 flag to guess if the incoming data was codepoints or bytes, which was a false presmise. Those lines are, unfortunately, only part of the problem. Other places exist in RT which blindly pass bytes (not characters) to textual columns, which need to be resolved in order for RT to work properly with DBD::Pg. In other words, the internals of RT are riddled with places that make the same false assumptions about the UTF-8 flag as DBD::Pg 3.2.1 did, which mostly canceled each other out. Could you say a bit more about the problem and what plans there are to fix/workaround it for RT? Forcing a lower version of DBD::Pg isn't a practical option in a packaged environment like Debian. I've pushed https://github.com/bestpractical/rt/tree/4.0/utf8-reckoning which addresses the deeper issues needed for RT to work. It is currently in review, and will be merged in as short order as a branch of that size can be. It passes all tests on both versions of DBD::Pg, but further testing (carefully, as it might cause data corruption with non-ASCII characters) would be appreciated. This is a pretty serious issue. Fixing this is indeed high priority for us, as mostly-unrecoverable data corruption is never a good thing. Once the branch gets merged, I expect we'll roll release candidates in short order. - Alex [1] This is a slight lie, due to perl internals. In some rare cases, for strings which contain only codepoints which exist in ISO-8859-1, it instead encodes them in ISO-8859-1 before treating those bytes as codepoints and double-encoding in UTF-8, for all of your mojibake needs. Wonderful, no? -- RT Training - Boston, September 9-10 http://bestpractical.com/training
