Quote:
The only thing I needed to disable was the "Restrict individual users" function that you had, other wise granting access to a user with userid = 20 also grants access to the usergroup with usergroupid = 20.
|
I really don't think so. Individual user info is kept between paranthesis () and checked this way too. So if you grant access to userid 20, the DB record is (20) but if you grant access to usergroupid, the record is just 20.
The section you commented out checks for paranthesis too so I wouldn't think it is allowing usergroupid 20 when you allowed userid 20.
Quote:
Example: If a user is a member of primary group 1 and secondary group A, If I try and block access to Primary Group 1 and allow access to Secondary Group A then the user will still not be allowed access because the way you have it written all users that are in primary group 1 are denied access.
|
I see what you are saying but this algorithm matches with its logic. Because this section of the hack is for marking "banned" usergroups so when you mark a usergroup, this means the hack shouldn't give access to any user who is part of this group. If the hack would give access due to that users belonging to another usergroup, it would be impossible to ban primary usergroups as their users might get access due to secondary usergroups which they join themselves.
I'm sure you'll agree that most of the admin's permission system would depend on "primary usergroups", not "secondary usergroups" so IMO how it is designed is make sense.