Hello,
I have RT-3.6.1, postgres backend, apache with mod_perl.
We just stumbled upon a funny situation. I’m hoping one of you is going
to be able to help me sort it out.
A few minutes ago, 2 helpdesk techs used the “take” button, at pretty
much the same time. Upon closer inspection, here are the interesting
bits:
The history, under “display”, of that ticket shows the following output
in the history:
[create ticket bits here]
Wed Feb 25 11:35:50 2009 Tom - Taken
Wed Feb 25 11:35:50 2009 Geoff - Taken
I asked Geoff to give the ticket back to Tom. When Geoff tried to set
the owner to Tom, RT threw an error: “Could not change owner. Group
already has member”. So it looks like “Owner” is a group that, for this
ticket, has 2 principals (which, I believe, it shouldn’t have). We tried
to “steal” the ticket, give it to nobody, and everytime, we get an error
"Could not change owner. Group already has member".
So the question is: how do I go about making the ticket behave properly?
I suppose I need to go into the DB and fix it there. And I suppose some
code probably needs to be fixed so that race condition doesn’t happen
(or is it fixed in newer versions?).
Thank you,
Jok
Hello,
I have RT-3.6.1, postgres backend, apache with mod_perl.
Todd Chapman patched this issue in RT quite a while back. I don’t
remember if it’s in 3.6.7, but I believe it is. It’s definitely fixed in
3.8.
Hello,
I have RT-3.6.1, postgres backend, apache with mod_perl.
Todd Chapman patched this issue in RT quite a while back. I don’t
remember if it’s in 3.6.7, but I believe it is. It’s definitely fixed in
3.8.
That was about 4 years ago! I think it was fixed in 3.6.2. It felt
good to find and fix that race condition. 
Will this cause issues with the upgrade process, if I update to 3.8.2 now?
(ie: will it just “recover” or will the DB choke on it)
I guess I could just shred that ticket… But history is important…
Jok
Joachim,
You could do this with SQL directly in the DataBase, but I would only
do that if Shredder can’t handle it. I’m afraid if you shred the ticket,
it’s gone and there won’t be a ticket to own. That might make your Audit
department a little testy about your ticket history. I have some SQL
that would help you, but you have to know it invloves more than just the
Ticket Table. There is the Group, Groupmember, ACL, etc. tables. There
is very little data in RT that does OT relate to other tables. They ALL
have to be insync.
Kenn
LBNLOn 2/26/2009 11:04 AM, Joachim Thuau wrote:
Will this cause issues with the upgrade process, if I update to 3.8.2 now?
(ie: will it just “recover” or will the DB choke on it)
I guess I could just shred that ticket… But history is important…
Jok
-----Original Message-----
From: Todd Chapman [mailto:todd@chaka.net]
Sent: Wednesday, February 25, 2009 11:30 PM
To: Jesse Vincent
Cc: Joachim Thuau; rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Ticket taken twice
On Wed, Feb 25, 2009 at 4:11 PM, Jesse Vincent jesse@bestpractical.com wrote:
On Wed 25.Feb’09 at 12:25:39 -0800, Joachim Thuau wrote:
Hello,
I have RT-3.6.1, postgres backend, apache with mod_perl.
Todd Chapman patched this issue in RT quite a while back. I don’t
remember if it’s in 3.6.7, but I believe it is. It’s
definitely fixed
in 3.8.
That was about 4 years ago! I think it was fixed in 3.6.2. It
felt good to find and fix that race condition.
We just stumbled upon a funny situation. I’m hoping one of you is
going to be able to help me sort it out.
A few minutes ago, 2 helpdesk techs used the “take”
button, at pretty
much the same time. Upon closer inspection, here are the
interesting
bits:
The history, under “display”, of that ticket shows the following
output in the history:
[create ticket bits here]
Wed Feb 25 11:35:50 2009 Tom - Taken
Wed Feb 25 11:35:50 2009 Geoff - Taken
I asked Geoff to give the ticket back to Tom. When Geoff
tried to set
the owner to Tom, RT threw an error: “Could not change
owner. Group
already has member”. So it looks like “Owner” is a group that, for
this ticket, has 2 principals (which, I believe, it
shouldn’t have).
We tried to “steal” the ticket, give it to nobody, and
everytime, we
get an error “Could not change owner. Group already has member”.
So the question is: how do I go about making the ticket
behave properly?
I suppose I need to go into the DB and fix it there. And I suppose
some code probably needs to be fixed so that race
condition doesn’t
happen (or is it fixed in newer versions?).
Thank you,
Jok
The rt-users Archives
Community help: http://wiki.bestpractical.com Commercial support:
sales@bestpractical.com
Discover RT’s hidden secrets with RT Essentials from
O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
–
The rt-users Archives
Community help: http://wiki.bestpractical.com Commercial support:
sales@bestpractical.com
Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
The rt-users Archives
Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com
Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Will this cause issues with the upgrade process, if I update to 3.8.2 now?
(ie: will it just “recover” or will the DB choke on it)
I guess I could just shred that ticket… But history is important…
It’s been a while, but I believe that if someone “steals” the ticket
from here, RT will self-correct.
I’m a little on the fence about this. I obviously want to “catch up” and
get up to 3.8.2 (whoohoo!) but I do need to sort out that ticket first
(at least it would make sense…) to make sure it’s not going to croak
on the reload of the DB. I have looked at the nice relational drawing
from the RT-Essential book, and from that I know better than just going
into the DB like that and mess with the ticket… I can probably work it
out, but I’d love to be able to get to keep that ticket (well, with the
fixed bits in it). Would you share that SQL bits? At least, it’ll give
me a starting point…
Thanks,
Jok
Sadly, we already tried that. We can change the owner every which way,
except for “tom” (who was the guy that worked on it).
Can you try this patch? It’s conceptually right but off the cuff. It’s against 3.8
but applies to recentish 3.6. It may need a tiny bit of massage to apply to 3.6.1
You’ll need to stop and start apache after making the change.
=== lib/RT/Ticket_Overlay.pm
— lib/RT/Ticket_Overlay.pm (revision 58932)
+++ lib/RT/Ticket_Overlay.pm (local)
@@ -2782,7 +2782,12 @@
# Delete the owner in the owner group, then add a new one
# TODO: is this safe? it’s not how we really want the API to work
# for most things, but it’s fast.
- my ( $del_id, $del_msg ) = $self->OwnerGroup->MembersObj->First->Delete();
Sadly, we already tried that. We can change the owner every which way,
except for “tom” (who was the guy that worked on it).
Can you try this patch? It’s conceptually right but off the cuff. It’s against 3.8
but applies to recentish 3.6. It may need a tiny bit of massage to apply to 3.6.1
Don’t apply this patch. It’s making the RT test suite explode. I have no
idea what it would do to your DB.
Joachim,
I'll do that in a bit. However, I would try Jesse's patch first. You
could ALSO write down all the info for the ticket and shred it and then
re-create it properly. Let me know how it goes with Jesse’s patch and
such. In the meantime, I’ll put together the SQL and instructions.
Kenn
LBNLOn 2/26/2009 11:34 AM, Joachim Thuau wrote:
I’m a little on the fence about this. I obviously want to “catch up” and
get up to 3.8.2 (whoohoo!) but I do need to sort out that ticket first
(at least it would make sense…) to make sure it’s not going to croak
on the reload of the DB. I have looked at the nice relational drawing
from the RT-Essential book, and from that I know better than just going
into the DB like that and mess with the ticket… I can probably work it
out, but I’d love to be able to get to keep that ticket (well, with the
fixed bits in it). Would you share that SQL bits? At least, it’ll give
me a starting point…
Thanks,
Jok
-----Original Message-----
From: Kenneth Crocker [mailto:KFCrocker@lbl.gov]
Sent: Thursday, February 26, 2009 11:22 AM
To: Joachim Thuau
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Ticket taken twice
Joachim,
You could do this with SQL directly in the DataBase,
but I would only do that if Shredder can’t handle it. I’m
afraid if you shred the ticket, it’s gone and there won’t be
a ticket to own. That might make your Audit department a
little testy about your ticket history. I have some SQL that
would help you, but you have to know it invloves more than
just the Ticket Table. There is the Group, Groupmember, ACL,
etc. tables. There is very little data in RT that does OT
relate to other tables. They ALL have to be insync.
Kenn
LBNL
The rt-users Archives
Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com
Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
I’ll do that in a bit. However, I would try Jesse’s patch first. You
could ALSO write down all the info for the ticket and shred it and then
re-create it properly. Let me know how it goes with Jesse’s patch and
such. In the meantime, I’ll put together the SQL and instructions.
Doesn’t the shredder make a SQL dump? You could shred it, edit the SQL
dump, and then reload it to the db. Just an idea.
Also note that Mr. Vincent said not to use the patch as its broken (in case
you missed that mail).
– ============================
Tom Lahti
BIT Statement LLC
(425)251-0833 x 117
http://www.bitstatement.net/
– ============================
Tom,
Yep. I got it after I wrote my last note. If what you say is true, then
that dump would be an excellant way to determine what records need to be
updated in the DataBase.
Kenn
LBNLOn 2/26/2009 12:32 PM, Tom Lahti wrote:
I’ll do that in a bit. However, I would try Jesse’s patch first. You
could ALSO write down all the info for the ticket and shred it and then
re-create it properly. Let me know how it goes with Jesse’s patch and
such. In the meantime, I’ll put together the SQL and instructions.
Doesn’t the shredder make a SQL dump? You could shred it, edit the SQL
dump, and then reload it to the db. Just an idea.
Also note that Mr. Vincent said not to use the patch as its broken (in case
you missed that mail).
I'll do that in a bit. However, I would try Jesse's patch first. You
could ALSO write down all the info for the ticket and shred it and then
re-create it properly. Let me know how it goes with Jesse’s patch and
such. In the meantime, I’ll put together the SQL and instructions.
Doesn’t the shredder make a SQL dump? You could shred it, edit the SQL
dump, and then reload it to the db. Just an idea.
I would like to caution people against editing raw SQL here. There’s a
bunch of nuance to group members and cached group members that is very
easy to get wrong. I expect to have a better patch (or discover that
the test suite failure was a red herring) within an hour or two.
Also note that Mr. Vincent said not to use the patch as its broken (in case
you missed that mail).
As a completely unimportant note on formality: Mr Vincent is my
grandfather. I’m Jesse. 
Best,
Jesse
Don’t apply this patch. It’s making the RT test suite explode. I have no
idea what it would do to your DB.
It was a false alarm. The test suite is now happy. Give it a shot?
aHA!
I didn’t get a chance to apply the patch, but we figured out a way to
keep the whole history. The only data that wasn’t preserved was the
creation time, but the history is there and valid. That was enough for
us. We created a new ticket, and merged the “broken one” into it. That
transferred all the data (history, requestors, etc) to the new one, but
not the owner. So at this point, we are at a good spot (at least I
think).
I’ll work next week on upgrading the setup to the latest and greatest!
(and I’ll report the success…)
Thanks,
Jok