Item11578: groupAllowsChange returns true when 'none' is set as the mapping manager

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.

-- GeorgeClark - 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.

-- GeorgeClark - 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 GROUPINFO{"AdminGroup" format="$allowschange"} 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.

Possible solution:

• 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.

-- GeorgeClark - 28 Feb 2012

This does not predate Foswiki; GROUPINFO was introduced by me in Item2154. the allowsChange code was by Sven in Item2387.

By my reading, groupAllowsChange 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."

AdminGroup will always able to modify itself - it's the Admin group - so any GROUPINFO on that group will show ALLOWSCHANGE for all members.

-- CrawfordCurrie - 10 Mar 2014

Commenting is disabled while not logged in