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
[email protected]
www.reply.it
[Blue Reply]
From: Joe Harris [mailto:[email protected]]
Sent: giovedì 4 ottobre 2012 13:37
To: Scotto Alberto
Cc: [email protected]
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
<[email protected]<mailto:[email protected]>> 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
[email protected]
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.
<<inline: blue.png>>
Title: DbVisualizer export output
select from Tickets
| Date: |
2012-10-04 14:59:32 |
| Rows: |
1 |
| Columns: |
25 |
| SQL Statement: |
SELECT *
FROM
Tickets t
where t.id=2985
|
| id |
EffectiveId |
Queue |
Type |
IssueStatement |
Resolution |
Owner |
Subject |
InitialPriority |
FinalPriority |
Priority |
TimeEstimated |
TimeWorked |
Status |
TimeLeft |
Told |
Starts |
Started |
Due |
Resolved |
LastUpdatedBy |
LastUpdated |
Creator |
Created |
Disabled |
| 2985 |
2985 |
46 |
ticket |
0 |
0 |
3444 |
Richiesta entry CNAME per nuove licenze FEV |
0 |
0 |
0 |
0 |
0 |
resolved |
0 |
(null) |
1970-01-01 00:00:00 |
2012-09-10 13:24:00 |
1970-01-01 00:00:00 |
2012-09-10 13:24:00 |
3444 |
2012-09-10 13:24:00 |
11821 |
2012-09-10 10:31:00 |
0 |
Select - Tickets join Users
| Date: |
2012-10-04 14:56:50 |
| Rows: |
1 |
| Columns: |
60 |
| SQL Statement: |
SELECT *
FROM
Tickets t join Users u on u.id=t.Owner
where t.id=2985
|
| id |
EffectiveId |
Queue |
Type |
IssueStatement |
Resolution |
Owner |
Subject |
InitialPriority |
FinalPriority |
Priority |
TimeEstimated |
TimeWorked |
Status |
TimeLeft |
Told |
Starts |
Started |
Due |
Resolved |
LastUpdatedBy |
LastUpdated |
Creator |
Created |
Disabled |
id |
Name |
Password |
AuthToken |
Comments |
Signature |
EmailAddress |
FreeformContactInfo |
Organization |
RealName |
NickName |
Lang |
EmailEncoding |
WebEncoding |
ExternalContactInfoId |
ContactInfoSystem |
ExternalAuthId |
AuthSystem |
Gecos |
HomePhone |
WorkPhone |
MobilePhone |
PagerPhone |
Address1 |
Address2 |
City |
State |
Zip |
Country |
Timezone |
PGPKey |
Creator |
Created |
LastUpdatedBy |
LastUpdated |
| 2985 |
2985 |
46 |
ticket |
0 |
0 |
3444 |
Richiesta entry CNAME per nuove licenze FEV |
0 |
0 |
0 |
0 |
0 |
resolved |
0 |
(null) |
1970-01-01 00:00:00 |
2012-09-10 13:24:00 |
1970-01-01 00:00:00 |
2012-09-10 13:24:00 |
3444 |
2012-09-10 13:24:00 |
11821 |
2012-09-10 10:31:00 |
0 |
3444 |
john.doe |
###### |
##### |
|
(null) |
[email protected] |
|
|
John Doe |
|
|
(null) |
(null) |
(null) |
(null) |
(null) |
(null) |
|
|
|
|
|
|
|
|
|
|
|
(null) |
(null) |
12 |
2012-03-07 11:04:54 |
12 |
2012-05-08 10:44:12 |
--------
Final RT training for 2012 in Atlanta, GA - October 23 & 24
http://bestpractical.com/training
We're hiring! http://bestpractical.com/jobs
