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 ?
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;
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
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 => ‘!=’ );
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 ?
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
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
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
=> ‘!=’ );
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 ?
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 => ‘!=’ );
