[rt-users] Setting owner with _Set breaks queries (may be a bug)
Scotto Alberto
al.scotto at reply.it
Thu Oct 4 09:09:04 EDT 2012
Joe,
Thank for you your quick answer!
I’ll take ticket #2985 as an example, which is one of those affected by the issue.
The scrip correctly happens in the transaction #38624, “Status changed from 'new' to 'resolved'”, as the (custom) scrip condition is (taken from the DB):
| 17 | On closure | If the status is set to inactive | StatusChange | old: initial, active; new: inactive | Status | 1 | 2012-05-30 15:54:19 | 1 | 2012-05-30 15:54:19 |
Here is some output from rt.log:
[Mon Sep 10 13:24:00 2012] [debug]: About to think about scrips for transaction #38624 (/opt/rt4/sbin/../lib/RT/Transaction.pm:173)
[Mon Sep 10 13:24:00 2012] [debug]: About to prepare scrips for transaction #38624 (/opt/rt4/sbin/../lib/RT/Transaction.pm:177)
[Mon Sep 10 13:24:00 2012] [debug]: Found 15 scrips for TransactionCreate stage with applicable type(s) Status for txn #38624 on ticket #2985 (/opt/rt4/sbin/../lib/RT/Scrips.pm:367)
[Mon Sep 10 13:24:00 2012] [debug]: Skipping Scrip #19 because it isn't applicable (/opt/rt4/sbin/../lib/RT/Scrips.pm:229)
[Mon Sep 10 13:24:00 2012] [debug]: Skipping Scrip #35 because it isn't applicable (/opt/rt4/sbin/../lib/RT/Scrips.pm:229)
[Mon Sep 10 13:24:00 2012] [debug]: Skipping Scrip #18 because it isn't applicable (/opt/rt4/sbin/../lib/RT/Scrips.pm:229)
[Mon Sep 10 13:24:00 2012] [debug]: Skipping Scrip #12 because it isn't applicable (/opt/rt4/sbin/../lib/RT/Scrips.pm:229)
[Mon Sep 10 13:24:00 2012] [debug]: Skipping Scrip #2 because it isn't applicable (/opt/rt4/sbin/../lib/RT/Scrips.pm:229)
[Mon Sep 10 13:24:00 2012] [debug]: Skipping Scrip #21 because it isn't applicable (/opt/rt4/sbin/../lib/RT/Scrips.pm:229)
[Mon Sep 10 13:24:00 2012] [debug]: Skipping Scrip #27 because it isn't applicable (/opt/rt4/sbin/../lib/RT/Scrips.pm:229)
[Mon Sep 10 13:24:00 2012] [debug]: Skipping Scrip #23 because it isn't applicable (/opt/rt4/sbin/../lib/RT/Scrips.pm:229)
[Mon Sep 10 13:24:00 2012] [debug]: Skipping Scrip #29 because it isn't applicable (/opt/rt4/sbin/../lib/RT/Scrips.pm:229)
[Mon Sep 10 13:24:00 2012] [debug]: Skipping Scrip #37 because it isn't applicable (/opt/rt4/sbin/../lib/RT/Scrips.pm:229)
[Mon Sep 10 13:24:00 2012] [debug]: Skipping Scrip #38 because it isn't applicable (/opt/rt4/sbin/../lib/RT/Scrips.pm:229)
[Mon Sep 10 13:24:00 2012] [debug]: About to commit scrips for transaction #38624 (/opt/rt4/sbin/../lib/RT/Transaction.pm:197)
[Mon Sep 10 13:24:00 2012] [debug]: Committing scrip #34 on txn #38624 of ticket #2985 (/opt/rt4/sbin/../lib/RT/Scrips.pm:183)
[Mon Sep 10 13:24:00 2012] [info]: Attempting to auto assign ticket #2985 to user #3444 ((eval 3201):12)
[Mon Sep 10 13:24:00 2012] [debug]: Committing scrip #10 on txn #38624 of ticket #2985 (/opt/rt4/sbin/../lib/RT/Scrips.pm:183)
[Mon Sep 10 13:24:00 2012] [debug]: Calling SetRecipientDigests for transaction RT::Transaction=HASH(0xe6582b0), id 38624 (/opt/rt4/sbin/../lib/RT/Action/SendEmail.pm:6
Attached you can find two queries I’ve just executed in my DB. It shows that the owner is correctly set as the id of the user John Doe.
Ø And the chart looks for the resolved transaction to get owner at the time of resolution?
I don’t think it’s a matter of transactions, as I think the chart queries tickets, not transactions.
Alberto Scotto
Blue Reply
Via Cardinal Massaia, 83
10147 - Torino - ITALY
phone: +39 011 29100
al.scotto at reply.it
www.reply.it
[Blue Reply]
From: Joe Harris [mailto:drey111 at gmail.com]
Sent: giovedì 4 ottobre 2012 13:37
To: Scotto Alberto
Cc: rt-users at lists.bestpractical.com
Subject: Re: [rt-users] Setting owner with _Set breaks queries (may be a bug)
This is a shot in the dark and I may be way off, but is there a chance your scrip to set the owner runs in a transaction that happens after the transaction that resolves the ticket?
And the chart looks for the resolved transaction to get owner at the time of resolution?
Just a thought.
Sent from my mobile device.
On Oct 4, 2012, at 7:05 AM, Scotto Alberto <al.scotto at reply.it<mailto:al.scotto at reply.it>> wrote:
Hi all,
I think I found a bug.
I have a scrip called "On closure Auto set owner", which sets the owner while closing the ticket in case nobody has never taken it, so that I don't get resolved tickets assigned to "Nobody in particular".
Everything seemed ok until today a colleague of mine noticed something weird with a chart that acts like a hall of fame, showing the top Owners. This chart is very simple: it retrieves all the tickets and it is grouped by Owner.RealName.
The weird thing is not the chart itself, but the fact that the following two queries should return the same tickets but they don’t:
- Owner.RealName = 'Nobody in particular' returns 706 tickets
- Owner = 'Nobody in particular' returns 369 tickets
The results of the former are not correct: it includes also the tickets for which the owner was set by my scrip, though the column “Owner” is correct (filled with “John Doe”, not “Nobody in particular”).
Here are the relevant lines of the code of my scrip:
# get actor ID
my $Actor = $self->TransactionObj->Creator;
my $tkt = $self->TicketObj;
# try to change owner
my ($status, $msg) = $tkt->_Set(Field => 'Owner', Value => $Actor, RecordTransaction => 0);
I solved the problem using SetOwner instead of _Set, like this:
my ($status, $msg) = $tkt->SetOwner($Actor);
With the new code, the tickets whose owner is set by my scrip don’t get caught by the query Owner.RealName = 'Nobody in particular'.
Looks like _Set doesn’t update correctly some field in some table in the DB. But I have no idea of what field and what table! I had a quick look at the DB, and it seems that the relation ticket-owner is based on an user ID, not a string (the real name).
Finally, a weird thing with the chart: on the right side, it displays all the owners and the number of tickets associated. For “Nobody in particular”, the number is 369 (correct); but if I click on this number it generates the query “Owner.RealName = 'Nobody in particular'” saying “Found 706 tickets”.
The questions are:
Should I file a bug?
How can I “convert” the tickets that were processed with the old code?
Hope everything is clear
Thank you very much!
Alberto Scotto
Blue Reply
Via Cardinal Massaia, 83
10147 - Torino - ITALY
phone: +39 011 29100
al.scotto at reply.it
www.reply.it
<blue.png>
________________________________
--
The information transmitted is intended for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
--------
Final RT training for 2012 in Atlanta, GA - October 23 & 24
http://bestpractical.com/training
We're hiring! http://bestpractical.com/jobs
________________________________
--
The information transmitted is intended for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20121004/20361dc4/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: blue.png
Type: image/png
Size: 2329 bytes
Desc: blue.png
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20121004/20361dc4/attachment.png>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20121004/20361dc4/attachment.html>
More information about the rt-users
mailing list