sturner at MIT
May 12, 2008, 11:33 AM
Post #1 of 1
(213 views)
Permalink
|
|
RT 3.6.5 Bug - Group Members Page
|
|
A change to Admin/Groups/Members.html that appeared somewhere
between 3.4.2 and 3.6.5 has introduced a bug.
The change in question is the sorting of the group's list of user
members. The change has caused this problem - if you add a group
(named, let's say, "subgroup") as a member of the group
("maingroup"), the user members of subgroup now appear in maingroup's
user members list. I'm sure this is not intended - for example, if
you try to remove one of these user members by checking the box, you
get the error message "Group has no such member".
The problem seems to have been caused by a change in how the group's
user members are obtained - from using the group's
MembersObj->LimitToUser method to using the UserMembersObj method.
The former returns only direct user members (which is what we want)
whereas the latter gives you user members of all subgroups as well,
which isn't what we want.
I can see why this was done - you can sort a query of Users by name,
whereas you can't sort GroupMembers by name. But the case where
groups are added as members doesn't seem to have been taken into account.
There are a number of solutions, which is why I haven't supplied a
patch. You could revert to using MembersObj->LimitToUser in the
Mason code and sort the data there. Or you could modify
UserMembersObj to take an argument ( something like
"IncludeSubgroupMembers") that would allow you to choose direct
members only or all subgroup members. And there are probably other
solutions (adding a Name attribute to GroupMember??)...
Thanks
Steve
_______________________________________________
List info: http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel
|
