Item12006: UserRegistration should not list NobodyGroup
Priority: Normal
Current State: Closed
Released In: 1.1.6
Target Release: patch
Users should never be added to
NobodyGroup, and since
distro:1207a7a3bad9 or so, that's not actually possible any more. But when a member of the
AdminGroup adds a user while REGISTRATIONGROUPTYPE = multiple,
NobodyGroup is still one of the listed options.
As an aside, when there are a lot of groups, people have become confused and checked the box after the group name, instead of before. It would help if the list is formatted in such a way that the groupname/checkbox relationship cannot be mistaken (e.g., two generously spaced columns).
--
FlorianSchlichting - 20 Jul 2012
NobodyGroup is listed because the TML in
DefaultUserRegistration relies on
GROUPINFO{show="allowchange"}, which for admin users will always return all existing groups, and has no other way to filter out certain results.
16:05 < gac410> That feature unfortunately still needs a bit of polishing.
16:06 < gac410> [off] Some of it ought to be done server side. automatic for example shouldn't allow client to influence the results.
--
FlorianSchlichting - 20 Jul 2012
hm. In looking at this,
GROUPINFO asks the mapper users->groupAllowsChange($cUID). I don't beleve that the mapper should never allow change to the
NobodyGroup.
TopicUserMapping.pm should probably return 0 for
NobodyGroup, even for admin users.
The Topic should still allow change and will be handled by ordinary ACLs, as an admin might want to add descriptive text. But from the mapper perspective, the membership cannot be changed.
--
GeorgeClark - 20 Jul 2012