Bug (Showstopper?) in 3.0.11rc2?

Dirk_Pape · May 19, 2004, 6:54am

I found, that (since 3.0.11rc1) in the select box (Elements/SelectOwner)
which is shown on Ticket/Update and other places to adjust the owner of a
Ticket, only “Nobody” and “root” are shown.

Before this we could see all Users which have OwnTicket rights on that
ticket or on the queue the ticket is in.

Is this obseved on aother places or is this specific to our installation?

Regards,
Dirk.

Jesse_Vincent · May 19, 2004, 6:58am

I found, that (since 3.0.11rc1) in the select box (Elements/SelectOwner)
which is shown on Ticket/Update and other places to adjust the owner of a
Ticket, only “Nobody” and “root” are shown.

Before this we could see all Users which have OwnTicket rights on that
ticket or on the queue the ticket is in.

Is this obseved on aother places or is this specific to our installation?

There was a change to SelectOwner that should have improved
performance by doing the right SQL query there, rather than the horrible
misquery that we were doing with recent searchbuilder revs. Just to be
sure, what searchbuilder rev are you running?

Jesse

Jesse_Vincent · May 19, 2004, 7:09am

I found, that (since 3.0.11rc1) in the select box (Elements/SelectOwner)
which is shown on Ticket/Update and other places to adjust the owner of a
Ticket, only “Nobody” and “root” are shown.

Before this we could see all Users which have OwnTicket rights on that
ticket or on the queue the ticket is in.

Is this obseved on aother places or is this specific to our installation?

There was a change to SelectOwner that should have improved
performance by doing the right SQL query there, rather than the horrible
misquery that we were doing with recent searchbuilder revs. Just to be
sure, what searchbuilder rev are you running?

For what it’s worth, I just brought our corporate RT instance up to
3.0.11rc3 and do not see this issue on Ticket/Update.html
Ticket/People.html or Ticket/Create.html

Dirk_Pape · May 19, 2004, 7:19am

Hallo Jesse,

–Am Mittwoch, 19. Mai 2004 3:09 Uhr -0400 schrieb Jesse Vincent
jesse@bestpractical.com:

For what it’s worth, I just brought our corporate RT instance up to
3.0.11rc3 and do not see this issue on Ticket/Update.html
Ticket/People.html or Ticket/Create.html

I forgot: I have rc3 since yesterday and have still the problem. apache is
restarted.

Dirk.

Dirk_Pape · May 19, 2004, 7:23am

Hallo Jesse,

–Am Mittwoch, 19. Mai 2004 2:58 Uhr -0400 schrieb Jesse Vincent
jesse@bestpractical.com:

There was a change to SelectOwner that should have improved
performance by doing the right SQL query there, rather than the horrible
misquery that we were doing with recent searchbuilder revs. Just to be
sure, what searchbuilder rev are you running?

Searchbuilder is version 0.99

Dirk.

Jesse_Vincent · May 19, 2004, 7:49am

can you try it with the dev snapshot of searchbuilder on CPAN?On Wed, May 19, 2004 at 09:23:07AM +0200, Dirk Pape wrote:

Hallo Jesse,

–Am Mittwoch, 19. Mai 2004 2:58 Uhr -0400 schrieb Jesse Vincent
jesse@bestpractical.com:

There was a change to SelectOwner that should have improved
performance by doing the right SQL query there, rather than the horrible
misquery that we were doing with recent searchbuilder revs. Just to be
sure, what searchbuilder rev are you running?

Searchbuilder is version 0.99

Dirk.

Senoner_Samuel · May 19, 2004, 1:01pm

I looked at cvs and it seems that SelectOwner in /html/elements have not been changed for 3.0.11rc3…
The last change before the tagging to rc3 was in november 2003.

Thanks for your explanations

Samuel-----Original Message-----
From: Jesse Vincent [mailto:jesse@bestpractical.com]
Sent: Wednesday,19 May,2004 08:58
To: Dirk Pape
Cc: rt-users
Subject: Re: [rt-users] Bug (Showstopper?) in 3.0.11rc2?

On Wed, May 19, 2004 at 08:54:29AM +0200, Dirk Pape wrote:

I found, that (since 3.0.11rc1) in the select box
(Elements/SelectOwner) which is shown on Ticket/Update and other
places to adjust the owner of a Ticket, only “Nobody” and “root” are shown.

Before this we could see all Users which have OwnTicket rights on that
ticket or on the queue the ticket is in.

Is this obseved on aother places or is this specific to our installation?

There was a change to SelectOwner that should have improved performance by doing the right SQL query there, rather than the horrible misquery that we were doing with recent searchbuilder revs. Just to be sure, what searchbuilder rev are you running?

Jesse
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

RT Developer and Administrator training is coming to LA, DC and Frankfurt this spring and summer.
http://bestpractical.com/services/training.html

Sign up early, as class space is limited.

Dirk_Pape · May 19, 2004, 5:55pm

Hello Jesse,

–Am Mittwoch, 19. Mai 2004 13:07 Uhr -0400 schrieb Jesse Vincent
jesse@bestpractical.com:

Grab
http://search.cpan.org/CPAN/authors/id/J/JE/JESSE/DBIx-SearchBuilder-1.00
_01.tar.gz

and hand-install it.

the bug is still there with DBIx-SearchBuilder-1.00_01.tar.gz

Does anybody else see this??

Dirk.

Jesse_Vincent · May 19, 2004, 5:59pm

Dirk,

Is this issue visible for you with a "vanilla" copy of RT

3.0.11rc3 or only one with your mods?

Jesse

Dirk_Pape · May 19, 2004, 6:51pm

Hello Jesse,

–Am Mittwoch, 19. Mai 2004 13:59 Uhr -0400 schrieb Jesse Vincent
jesse@bestpractical.com:

Is this issue visible for you with a “vanilla” copy of RT
3.0.11rc3 or only one with your mods?

I will try in the next days with a vanilla copy. I cannot swear, that this
bug appeared first in 3.0.11rc2 or if it was already present in 3.0.10.

It would be nice if there were some more people saying me: “yes, they can
see the bug, too” or “no, all is alright”.

I recently changed from a mod_perl setup to fast_cgi. Perhaps that is
something to be rewinded?

Dirk.

Dirk_Pape · May 19, 2004, 7:38pm

Hello Jesse,

–Am Mittwoch, 19. Mai 2004 20:51 Uhr +0200 schrieb Dirk Pape
pape-rt@inf.fu-berlin.de:

I recently changed from a mod_perl setup to fast_cgi. Perhaps that is
something to be rewinded?

switching back to mod_perl did not help here.

Dirk.

Ruslan_U_Zakirov · May 20, 2004, 6:46am

Dirk, I’ve rechecked with own setup

with old DB
with fresh DB
with fresh install
with local overlays.
All fine I don’t see glitch.

Dirk, I think you should create new fresh install without any extensions
and try it.

Also send us SQL query which is generated.

		Best regards. Ruslan.

Dirk Pape wrote:

Dirk_Pape · May 20, 2004, 7:46am

Hello Ruslan,

–Am Donnerstag, 20. Mai 2004 10:46 Uhr +0400 schrieb “Ruslan U. Zakirov”
cubic@acronis.ru:

Dirk, I’ve rechecked with own setup

with old DB

with fresh DB

with fresh install

with local overlays.
All fine I don’t see glitch.

Dirk, I think you should create new fresh install without any extensions
and try it.

Thanks, I will do so.

Also send us SQL query which is generated.

Hmh, so I eventually will have to learn how to do this by reading all the
mails about debugging SearchBuilder and monitoring mysql.

One never stops learning.

Dirk.

Ruslan_U_Zakirov · May 20, 2004, 8:13am

Dirk Pape wrote:

Hello Ruslan,

–Am Donnerstag, 20. Mai 2004 10:46 Uhr +0400 schrieb “Ruslan U.
Zakirov” cubic@acronis.ru:

Dirk, I’ve rechecked with own setup

with old DB

with fresh DB

with fresh install

with local overlays.
All fine I don’t see glitch.

Dirk, I think you should create new fresh install without any extensions
and try it.

Thanks, I will do so.

Also send us SQL query which is generated.

Hmh, so I eventually will have to learn how to do this by reading all
the mails about debugging SearchBuilder and monitoring mysql.

You can skip SB debug.
Just add
log=/var/log/mysql_full.log
to [mysqld] section into my.cnf in /etc.
then do one page refresh and look into log.

Dirk_Pape · May 21, 2004, 9:35am

Hello Ruslan, hello Jesse,

–Am Donnerstag, 20. Mai 2004 12:13 Uhr +0400 schrieb “Ruslan U. Zakirov”
cubic@acronis.ru:

You can skip SB debug.
Just add
log=/var/log/mysql_full.log
to [mysqld] section into my.cnf in /etc.
then do one page refresh and look into log.

I could not do complete testing (because yesterday was “party” and today I
am on vacation) but I have an “interim report”:

I catched the sql query out of the log (reformatted and attached!), which
if executed manually does not reveil the expected users either.

I think I need to describe the ACL situation, which might be different to
your scenarios:

Right “OwnTicket” is granted for global rule “AdminCC”
There exists an AdminCC group for Queue 9 which consists of six users
There does not exists an AdminCC group for Ticket 8317

The six users from (2.) are not found by the sql statement but only root,
system and nobody.

I continue testing this evening (vanilla install a. s. o.)

Dirk.

sql-statement.log (828 Bytes)

Dirk_Pape · May 21, 2004, 12:50pm

Hello,

–Am Freitag, 21. Mai 2004 11:35 Uhr +0200 schrieb Dirk Pape
pape-rt@inf.fu-berlin.de:

I catched the sql query out of the log (reformatted and attached!), which
if executed manually does not reveil the expected users either.

On the first view, I find the SQL-Statement to be buggy. It should at least
be

  OR (((main.Domain = 'RT::Queue-Role' AND main.Instance = 9)
         OR (main.Domain = 'RT::Ticket-Role' AND main.Instance = 8317))
     AND main.Type = ACL_1.PrincipalType) )

instead of

  OR (((main.Domain = 'RT::Queue-Role' AND main.Instance = 9)
         OR (main.Domain = 'RT::Ticket-Role' AND main.Instance = 8317))
     AND main.Type = ACL_1.PrincipalType
     AND main.id = ACL_1.PrincipalId) )

to match a Queue-defined AdminCC group to the globally defined AdminCC
rights, which is the sitiation missed in my case.

I do not know yet if the generated SQL statement is due to one of my
extensions or due to vanilla rt 3.0.11 code, but I think the latter is the
case, so this should be a real bug.

Ruslan, can you verify If you have granted “OwnTicket” right to AdminCC on
queue or on global level, in the case where you found, that it turned out
to be alright for you?

Dirk.

Jesse_Vincent · May 21, 2004, 3:07pm

Hello,

–Am Freitag, 21. Mai 2004 11:35 Uhr +0200 schrieb Dirk Pape
pape-rt@inf.fu-berlin.de:

I catched the sql query out of the log (reformatted and attached!), which
if executed manually does not reveil the expected users either.

On the first view, I find the SQL-Statement to be buggy. It should at least
be
 OR (((main.Domain = 'RT::Queue-Role' AND main.Instance = 9)
        OR (main.Domain = 'RT::Ticket-Role' AND main.Instance = 8317))
    AND main.Type = ACL_1.PrincipalType) )
instead of
 OR (((main.Domain = 'RT::Queue-Role' AND main.Instance = 9)
        OR (main.Domain = 'RT::Ticket-Role' AND main.Instance = 8317))
    AND main.Type = ACL_1.PrincipalType
    AND main.id = ACL_1.PrincipalId) )
to match a Queue-defined AdminCC group to the globally defined AdminCC
rights, which is the sitiation missed in my case.

I do not know yet if the generated SQL statement is due to one of my
extensions or due to vanilla rt 3.0.11 code, but I think the latter is the
case, so this should be a real bug.

Ruslan, can you verify If you have granted “OwnTicket” right to AdminCC on
queue or on global level, in the case where you found, that it turned out
to be alright for you?

Dirk,
Off the top of my head, I’m not sure what’s changed between
3.0.10 and 3.0.11 that would cause such a query change. Is this ACL
setup new for you or did it work fine in vanilla 3.0.10?

Jesse_Vincent · May 22, 2004, 12:20am

(sorry for the top-post, I’m on a slow link)
The change in Users_Overlay.pm is intentional. It should merely have
removed the joins to the principals table, since they don’t actually
gain us anything. I agree that there may be something else there that
broke. I’ll look into it over the weekend. But the change is due to the
fact that we don’t need the principals table on this query and that
postgres does something kind of braindead here that causes us to have a
catastropchic performance failre.
I will have a look at this. And do appreciate the failure case. Now I
can craft a test that fails so I know when I’ve fixed it and it never
happens again.

JesseOn Fri, May 21, 2004 at 09:02:55PM +0200, Dirk Pape wrote:

Hello Jesse,

–Am Freitag, 21. Mai 2004 17:31 Uhr +0200 schrieb Dirk Pape
pape-rt@inf.fu-berlin.de:

my ACL setup is much older than 3.0.10 and with this mail I send you
Groups_Overlay.pm from 3.0.10 and 3.0.11rc3 which differ in “WithRights”.

from looking at the diff I am quite sure there is the bug.

now I had time to test. Reverting the method Groups->WithRights to the
version in RT 3.0.10 reestablished good (for me!) behaviour.

If you had no intentional change in WithRights, I request going back to the
3.0.10 version before releasing 3.0.11. Patch is attached.

Thanks,
Dirk.

Jesse_Vincent · May 23, 2004, 10:14pm

I catched the sql query out of the log (reformatted and attached!), which
if executed manually does not reveil the expected users either.

On the first view, I find the SQL-Statement to be buggy. It should at least
be
 OR (((main.Domain = 'RT::Queue-Role' AND main.Instance = 9)
        OR (main.Domain = 'RT::Ticket-Role' AND main.Instance = 8317))
    AND main.Type = ACL_1.PrincipalType) )
instead of
 OR (((main.Domain = 'RT::Queue-Role' AND main.Instance = 9)
        OR (main.Domain = 'RT::Ticket-Role' AND main.Instance = 8317))
    AND main.Type = ACL_1.PrincipalType
    AND main.id = ACL_1.PrincipalId) )
to match a Queue-defined AdminCC group to the globally defined AdminCC
rights, which is the sitiation missed in my case.

That is 100% correct. My testing confirmed this. I’ve just built new
tests into RT to make sure this doesn’t happen again and altered the
query to behave apropriately. Regression tests are running now.

Ruslan_U_Zakirov · May 24, 2004, 12:41am

Jesse Vincent wrote:

I catched the sql query out of the log (reformatted and attached!), which
if executed manually does not reveil the expected users either.

On the first view, I find the SQL-Statement to be buggy. It should at least
be
OR (((main.Domain = 'RT::Queue-Role' AND main.Instance = 9)
       OR (main.Domain = 'RT::Ticket-Role' AND main.Instance = 8317))
   AND main.Type = ACL_1.PrincipalType) )
instead of
OR (((main.Domain = 'RT::Queue-Role' AND main.Instance = 9)
       OR (main.Domain = 'RT::Ticket-Role' AND main.Instance = 8317))
   AND main.Type = ACL_1.PrincipalType
   AND main.id = ACL_1.PrincipalId) )
to match a Queue-defined AdminCC group to the globally defined AdminCC
rights, which is the sitiation missed in my case.
That is 100% correct. My testing confirmed this. I’ve just built new
tests into RT to make sure this doesn’t happen again and altered the
query to behave apropriately. Regression tests are running now.
After playing around this I end up with attached patch.

global_rigths_delegation.patch (1.33 KB)