Features / Usability

Posted by SEWilco 26 Jul 2009 03:29 GMT-0000 posts: 26

Keeping in mind that we're playing with Admin which is misbehaving, you should back up your database before tinkering...in case something goes wrong.

The greyed out boxes indicate that the permission is inherited from another group. Perhaps someone tried to "include" the group Admin into Admins. Look at the top of the Edit Permissions page for Admins, where there is a red "X" next to the groups which are being inherited. If there is a red "X" next to the group Admin, click on the X to remove Admin from Admins.

Posted by Gary Cunningham-Lee 26 Jul 2009 13:15 GMT-0000 posts: 4656

I also don't understand why the permissions that aren't inherited are greyed out. (The ones that are inherited are greyed out because groups that contain groups logically must have the permissions that the contained groups have.) It seems to me that the not-inherited permissions should be available to turn off, so it seems like some permissions were given an "on for Admin" status by default and there's no way in the permissions interface to turn them off for Admin. I don't see the reason for this, so think it may be a bug.

But isn't it the case that the site admin (and any member that's in the Admin group) when Admin group has the tiki_p_admin permission has admin-level capabilities anyway, for any feature that's turned on? So there's no point in "turning off" a permission for the Admin group because the god-like power of tiki_p_admin overrides the specific permission, whether it's turned on or off. Isn't this true? For example, although freetags are turned on at a Tiki 3 site of mine, no group has the tiki_p_unassign_freetags permission, not even the Admin group explicitly. But Admin group members can unassign freetags, because they have tiki_p_admin permission.

This suggests to me that it doesn't make sense to try to "remove" permissions from the Admin group, because (though I haven't tested it) I have a hunch this wouldn't have any effect.

If some users need to have some admin capabilities but not others, they shouldn't be in the Admin group, but a new group should be made for them, that doesn't have the tiki_p_admin super-permission.

(Please point out if I'm wrong about this. I seem to recall having to assign perms to the Admin group, which shouldn't be needed if my theory above is true.)

-- Gary