groupAllowsChange returns true when 'none' is set as the mapping manager
Current State: Closed
Released In: 1.2.0
Target Release: minor
Users.pm sets the mapper to TopicUserMapping if the mapper is set to 'none.
This results in the %GROUPINFO macro, format=$allowschange returning true even though groups cannot be modified.
This appears to have existed pre-Foswiki.
- 28 Feb 2012
Also, it returns true even if no user is logged in. VarGROUPINFO
documents $allowschange as "$allowschange returns 0 (false) or 1 (true) if that group can be modified by the current user."
So the connection to the underlying mapper is wrong, as is the authorization check.
- 28 Feb 2012
It gets worse. Users.pm seems to suggest that groupAllowsChange API is used to return whether or not the group itself allows change. However GROUPINFO
calls groupAllowsChange for each member of the group, calling the API for each user (or group) in the group.
The AdminGroup by default, has a single permanent user - AdminUser. Calling
opens an iterator which returns a single member. It then calls groupAllowsChange for that topic -.BaseUserMapping_333. TopicUserMapper
gets control and returns true - even as WikiGuest
- no user logged in.
I think that the issue is topic BaseUserMapping
_333 is not a valid topic, the Main web doesn't restrict change. So Web permissions are applied.
We are also left with a bit of a hole in that there is no way to determine if the Group itself allows change. We can't check topic permissions, because the group might be implemented in a mapper that doesn't use topics.
- Resolve the inheritance issue for groupAllowsChange
- If Mapper is 'none' it should not assume that TopicUserMapper applies
- BaseUserMapping_* users should not make it into the TopicUserMapper code.
- GROUPINFO needs a parameter to request attributes of the group itself instead of group members
- Add "none" argument for show.
show="none" cause GROUPINFO to only return information about the group itself and not iterate the members.
- Need to better define groupAllowsChange and groupAllowsView when called for a User type group member. What about for mappers where the user does not exist in topic form.
- Foswiki::UserMapping should throw errors if the mapper doesn't implement addUserToGroup or removeUserFromGroup
This is beginning to sound like a feature proposal, but it's really broken.
- 28 Feb 2012
This does not predate Foswiki; GROUPINFO
was introduced by me in Item2154
code was by Sven in Item2387
By my reading,
is working correctly. However, as you say, the documentation states that:
"$allowschange returns 0 (false) or 1 (true) if that group can be modified by the current user."
This documentation is incorrect. It should read:
"$allowschange returns 0 (false) or 1 (true) if that group can be modified by the *user or group being shown."
will always able to modify itself - it's the Admin group - so any GROUPINFO
on that group will show
for all members.
- 10 Mar 2014