Issues with RT-3.0.10 and DBIx::SearchBuilder 0.99

Finally, we’ve found why we got a full list of users when we tried to
add a new member to a group.

We didn’t have that problem, with RT-3.0.9 and DBIx::SearchBuilder 0.97.

We tracked down the call to
share/html/Admin/Elements/SelectNewGroupMembers. Next we enabled the
logging in mysql. It appeared that the requests are different between
DBIx::SearchBuilder 0.97 and the newest one.

Here are the sql requests on RT-3.0.10 with DBIx::SearchBuilder 0.97 and
on RT-3.0.10 with DBIx::SearchBuilder 0.99 :

#DBIx::SearchBuilder 0.97
SELECT DISTINCT main.* FROM
Users main,
Principals Principals_1,
CachedGroupMembers CachedGroupMembers_2
WHERE ((CachedGroupMembers_2.GroupId = ‘4’))
AND ((Principals_1.Disabled = ‘0’))
AND ((Principals_1.PrincipalType = ‘User’))
AND ((main.id != ‘1’)or(main.id != ‘10’))
AND main.id = Principals_1.id
AND Principals_1.id = CachedGroupMembers_2.MemberId
ORDER BY main.Name ASC;

#DBIx::SearchBuilder 0.99
SELECT DISTINCT main.* FROM
Users main,
Principals Principals_1,
CachedGroupMembers CachedGroupMembers_2
WHERE ((CachedGroupMembers_2.GroupId = ‘4’))
AND ((Principals_1.Disabled = ‘0’))
AND ((Principals_1.PrincipalType = ‘User’))
AND ((Principals_1.id = CachedGroupMembers_2.MemberId))
AND ((main.id = Principals_1.id)or(main.id != ‘1’)or(main.id != ‘10’))
ORDER BY main.Name ASC;

I doubt they’re equivalent.

Should I downgrade to 0.97 ? Is there any other way to fix it ?

Regards,

Manuel

I also have this issue with SB 0.99 and 3.0.9, I did fallback to SB 0.97.

Manuel de Ferran wrote:

Finally, we’ve found why we got a full list of users when we tried to
add a new member to a group.

We didn’t have that problem, with RT-3.0.9 and DBIx::SearchBuilder 0.97.

We tracked down the call to
share/html/Admin/Elements/SelectNewGroupMembers. Next we enabled the
logging in mysql. It appeared that the requests are different between
DBIx::SearchBuilder 0.97 and the newest one.

Here are the sql requests on RT-3.0.10 with DBIx::SearchBuilder 0.97 and
on RT-3.0.10 with DBIx::SearchBuilder 0.99 :

#DBIx::SearchBuilder 0.97
SELECT DISTINCT main.* FROM
Users main,
Principals Principals_1,
CachedGroupMembers CachedGroupMembers_2
WHERE ((CachedGroupMembers_2.GroupId = ‘4’))
AND ((Principals_1.Disabled = ‘0’))
AND ((Principals_1.PrincipalType = ‘User’))
AND ((main.id != ‘1’)or(main.id != ‘10’))
AND main.id = Principals_1.id
AND Principals_1.id = CachedGroupMembers_2.MemberId
ORDER BY main.Name ASC;

#DBIx::SearchBuilder 0.99
SELECT DISTINCT main.* FROM
Users main,
Principals Principals_1,
CachedGroupMembers CachedGroupMembers_2
WHERE ((CachedGroupMembers_2.GroupId = ‘4’))
AND ((Principals_1.Disabled = ‘0’))
AND ((Principals_1.PrincipalType = ‘User’))
AND ((Principals_1.id = CachedGroupMembers_2.MemberId))
AND ((main.id = Principals_1.id)or(main.id != ‘1’)or(main.id != ‘10’))
ORDER BY main.Name ASC;

ORs are wrong. IMHO It should be ANDs.

hi all,

i’ve done a diff between 0.99 and 0.97.
Join method has changed in handle, and it use Limit method instead of
$table_links. wich is a good way, and it shows up this bug :wink:

so after a bit debuggin’ i finally found that the best way to fix this is to
modify Manson template :

  • share/html/Admin/Elements/SelectNewGroupMembers

replace the lines :

$users->Limit(FIELD => ‘id’, VALUE => $RT::SystemUser->id, OPERATOR => ‘!=’ );
$users->Limit(FIELD => ‘id’, VALUE => $RT::Nobody->id, OPERATOR => ‘!=’ );

with

$users->Limit(FIELD => ‘id’, VALUE => $RT::SystemUser->id, OPERATOR => ‘!=’
,ENTRYAGGREGATOR =>‘AND’);
$users->Limit(FIELD => ‘id’, VALUE => $RT::Nobody->id, OPERATOR => ‘!=’
,ENTRYAGGREGATOR =>‘AND’);

and it should work.Le Jeudi 22 Avril 2004 15:01, Ruslan U. Zakirov a écrit :

I also have this issue with SB 0.99 and 3.0.9, I did fallback to SB 0.97.

Manuel de Ferran wrote:

Finally, we’ve found why we got a full list of users when we tried to
add a new member to a group.

We didn’t have that problem, with RT-3.0.9 and DBIx::SearchBuilder 0.97.

We tracked down the call to
share/html/Admin/Elements/SelectNewGroupMembers. Next we enabled the
logging in mysql. It appeared that the requests are different between
DBIx::SearchBuilder 0.97 and the newest one.

Here are the sql requests on RT-3.0.10 with DBIx::SearchBuilder 0.97 and
on RT-3.0.10 with DBIx::SearchBuilder 0.99 :

#DBIx::SearchBuilder 0.97
SELECT DISTINCT main.* FROM
Users main,
Principals Principals_1,
CachedGroupMembers CachedGroupMembers_2
WHERE ((CachedGroupMembers_2.GroupId = ‘4’))
AND ((Principals_1.Disabled = ‘0’))
AND ((Principals_1.PrincipalType = ‘User’))
AND ((main.id != ‘1’)or(main.id != ‘10’))
AND main.id = Principals_1.id
AND Principals_1.id = CachedGroupMembers_2.MemberId
ORDER BY main.Name ASC;

#DBIx::SearchBuilder 0.99
SELECT DISTINCT main.* FROM
Users main,
Principals Principals_1,
CachedGroupMembers CachedGroupMembers_2
WHERE ((CachedGroupMembers_2.GroupId = ‘4’))
AND ((Principals_1.Disabled = ‘0’))
AND ((Principals_1.PrincipalType = ‘User’))
AND ((Principals_1.id = CachedGroupMembers_2.MemberId))
AND ((main.id = Principals_1.id)or(main.id != ‘1’)or(main.id != ‘10’))
ORDER BY main.Name ASC;

ORs are wrong. IMHO It should be ANDs.

I doubt they’re equivalent.

Should I downgrade to 0.97 ? Is there any other way to fix it ?

Regards,

Manuel


Rt-devel mailing list
Rt-devel@lists.bestpractical.com
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel


Rt-devel mailing list
Rt-devel@lists.bestpractical.com
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel

freely yours,
@issam

Yes, you are right. Could you create patch and send it here.
diff -u share/html/Admin/Elements/SelectNewGroupMembers.orig
share/html/Admin/Elements/SelectNewGroupMembers

		Best regards. Ruslan.

BAZZAOUI Aissam wrote:

patch attached

Yes, you are right. Could you create patch and send it here.
diff -u share/html/Admin/Elements/SelectNewGroupMembers.orig>
share/html/Admin/Elements/SelectNewGroupMembers

  	Best regards. Ruslan.

BAZZAOUI Aissam wrote:

hi all,

i’ve done a diff between 0.99 and 0.97.
Join method has changed in handle, and it use Limit method instead of
$table_links. wich is a good way, and it shows up this bug :wink:

so after a bit debuggin’ i finally found that the best way to fix this is
to modify Manson template :

  • share/html/Admin/Elements/SelectNewGroupMembers

replace the lines :

$users->Limit(FIELD => ‘id’, VALUE => $RT::SystemUser->id, OPERATOR =>
’!=’ ); $users->Limit(FIELD => ‘id’, VALUE => $RT::Nobody->id, OPERATOR
=> ‘!=’ );

with

$users->Limit(FIELD => ‘id’, VALUE => $RT::SystemUser->id, OPERATOR =>
’!=’ ,ENTRYAGGREGATOR =>‘AND’);
$users->Limit(FIELD => ‘id’, VALUE => $RT::Nobody->id, OPERATOR => ‘!=’
,ENTRYAGGREGATOR =>‘AND’);

and it should work.

I also have this issue with SB 0.99 and 3.0.9, I did fallback to SB 0.97.

Manuel de Ferran wrote:

Finally, we’ve found why we got a full list of users when we tried to
add a new member to a group.

We didn’t have that problem, with RT-3.0.9 and DBIx::SearchBuilder 0.97.

We tracked down the call to
share/html/Admin/Elements/SelectNewGroupMembers. Next we enabled the
logging in mysql. It appeared that the requests are different between
DBIx::SearchBuilder 0.97 and the newest one.

Here are the sql requests on RT-3.0.10 with DBIx::SearchBuilder 0.97 and
on RT-3.0.10 with DBIx::SearchBuilder 0.99 :

#DBIx::SearchBuilder 0.97
SELECT DISTINCT main.* FROM
Users main,
Principals Principals_1,
CachedGroupMembers CachedGroupMembers_2
WHERE ((CachedGroupMembers_2.GroupId = ‘4’))
AND ((Principals_1.Disabled = ‘0’))
AND ((Principals_1.PrincipalType = ‘User’))
AND ((main.id != ‘1’)or(main.id != ‘10’))
AND main.id = Principals_1.id
AND Principals_1.id = CachedGroupMembers_2.MemberId
ORDER BY main.Name ASC;

#DBIx::SearchBuilder 0.99
SELECT DISTINCT main.* FROM
Users main,
Principals Principals_1,
CachedGroupMembers CachedGroupMembers_2
WHERE ((CachedGroupMembers_2.GroupId = ‘4’))
AND ((Principals_1.Disabled = ‘0’))
AND ((Principals_1.PrincipalType = ‘User’))
AND ((Principals_1.id = CachedGroupMembers_2.MemberId))
AND ((main.id = Principals_1.id)or(main.id != ‘1’)or(main.id !=
‘10’)) ORDER BY main.Name ASC;

ORs are wrong. IMHO It should be ANDs.

I doubt they’re equivalent.

Should I downgrade to 0.97 ? Is there any other way to fix it ?

Regards,

Manuel


Rt-devel mailing list
Rt-devel@lists.bestpractical.com
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel


Rt-devel mailing list
Rt-devel@lists.bestpractical.com
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel

freely yours,
@issam


Rt-devel mailing list
Rt-devel@lists.bestpractical.com
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel


Rt-devel mailing list
Rt-devel@lists.bestpractical.com
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel

freely yours,
@issam

SelectNewGroupMembers.patch (721 Bytes)

patch attached

Thanks. Good catch, all. This will be in 3.0.11.

Hi folks,

DBIx::SearchBuilder 0.99 unmasked a pre-existing bug in RT, which is
why some of you have seen the problems described with the Group
Membership page. This bug is described in ticket #5587 at
http://rt3.fsck.com/.

I’ve applied Aissam’s patch, and it will be available in RT 3.0.11,
which we expect to be released next week.

If you’re using RT version 3.0.10 or lower, we recommend that you do
upgrade to DBIx::SearchBuilder 0.99, and make Aissam’s suggested
changes to RT.

Many thanks to Aissam for the patch, and the description of the
problem.

Thanks,
Linda

modify Manson template :

  • share/html/Admin/Elements/SelectNewGroupMembers

replace the lines :

$users->Limit(FIELD => ‘id’, VALUE => $RT::SystemUser->id, OPERATOR => ‘!=’ );
$users->Limit(FIELD => ‘id’, VALUE => $RT::Nobody->id, OPERATOR => ‘!=’ );

with

$users->Limit(FIELD => ‘id’, VALUE => $RT::SystemUser->id, OPERATOR => ‘!=’
,ENTRYAGGREGATOR =>‘AND’);
$users->Limit(FIELD => ‘id’, VALUE => $RT::Nobody->id, OPERATOR => ‘!=’
,ENTRYAGGREGATOR =>‘AND’);

and it should work.