MyBB Community Forums

Full Version: BUG!? Problem with custom secondary user groups
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I setup my board like this:

I have a forum group called "Project Forums".  Under Projects are a series of forums with individual project names -- such as "Project1", "Project2", etc.  Underneath each of those is a subforum or two that breaks out the tasks associated with the Projects.  i.e. "Task1", etc.

So, in total, I have:
Project Forums (just a group - not an "act as forum")
- Project1
-- Task1
-- Task2
- Project2
...

As far as permissions go, all registered users can currently read/write to both the "Project Forums" (group) & the individual "Projectx" forums.  However, I want to maintain individual control at the Task level.  So, I setup a custom user group called "Task1" and gave certain registered users Task1 as a secondary group.  Then, in the task's forum permissions section, I set it so that only Admins, Moderators (super&reg), and members of Task1 could even view it.  Everyone else - including all other registered users - are blocked.

Unfortunately, this is NOT working.  Being a secondary member of the custom user group does not count for gaining access to the forum if you are not marked registered, moderator, or admin.  I tried moving a test account to have Task1 as his primary group instead of secondary, and that worked fine.

I'm pretty much at a loss here.  Do you guys have any suggestions?
NOTE:  I tried doing this one level of forums up (at the Projectx level) and it failed too.  I created a group called "Project1" and made some test folks secondary members to it.  (They were primary members of the "registered users" group.)  I set the forum permissions to NOT allow registered users to even view anything, but to allow Project1 members full access.  Unfortunately, none of my test accounts could see the Project1 forums when it was configured like this. Sad

Making the user's Primary group = Project1 fixed the problem, but that's not a solution I can live with.  I need to be able to have general registered users that I can add - even for just a few days - to a handful of secondary groups to let them have access just to the information they need.

This is seeming like a bug in the code.  Perhaps secondary memberships are not being considered when deciding whether a user can access certain forums?

Is it a bug, or am I doing something wrong?
I've spent a chunk of time with the code, and I think I'm getting closer to figuring this out.  My focus so far has been the forum_permissions() and fetch_forum_permissions() functions.

In forum_permissions($fid=0, $uid=0, $gid=0), i have noticed the following:
...
		if($uid != $mybb->user['uid'])
		{
			if($usercache[$uid])
			{
				$query = $db->query("SELECT * FROM ".TABLE_PREFIX."users WHERE uid='$uid'");
				$usercache[$uid] = $db->fetch_array($query);
			}
			$gid = $usercache[$uid]['usergroup'].",".$usercache[$uid]['additionalgroups'];
			$groupperms = usergroup_permissions($gid);
		}
		else
		{
			$gid = $mybb->user['usergroup'];
			if(isset($mybb->user['additionalgroups']))
			{
				$gid .= ",".$mybb->user['additionalgroups'];
			}
			$groupperms = $mybb->usergroup;
...

Why is this last line shown above not equal to
$groupperms = usergroup_permissions($gid);
as it is in the "if" case???  Setting
$groupperms = $mybb->usergroup;
breaks the potential to support multiple groups, right?  This is just the primary group.  Should this be changed?

(Even if so, it doesn't totally fix my problem - although I do think it gets me closer.)

Secondly, I'm trying to wrap my head around the forums perms stored in $fpermcache and displayed in the Admin CPs Cache Manager.  If I'm reading this structure correctly, it goes something like this:
Array
(
    [20] => Array    (index, fid = 20)
        (
            [1] => Array    (usergroup, gid=1 = unregistered)
                (
                    [pid] => 57
                    [fid] => 20  (should line up with top-level fid, right?  Here it does.)
                    [gid] => 1  (should line up with top-level gid, right?  Here it does.)
                    ...
                )

            [2] => Array    (usergroup, 2 = registered)
                (
                    [pid] => 58
                    [fid] => 20  (should line up with top-level fid index, right?  Here it does again.)
                    [gid] => 2  (should line up with top-level gid, right?  Here it does.)
                    ...
                )
                 ...

That all makes sense to me.  But after those initial few, I start getting mismatches:
    [8] => Array    (index, fid = 8)
        (
            [1] => Array
                (
                    [pid] => 63
                    [fid] => 7  (fid=7 does NOT match with index, fid=8 above.  Is this ok?)
                    [gid] => 1  (should line up with top-level gid, right?  Here it does.)
                    ...
                )

            [5] => Array
                (
                    [pid] => 64
                    [fid] => 7  (fid=7 does NOT match with index, fid=8 above.  Is this ok?)
                    [gid] => 5  (should line up with top-level gid, right?  Here it does.)
                    ...
                )

Is this correct?  I have moved some threads around and done some reorganization, and it seems my gids always line up but my fids don't.  The board seems to run ok like this (short of the secondary permissions problems I'm having), but it's confusing me as to how this is used if it's correct. This looks like a problem to me, and would go a long way toward explaining the oddiities I'm seeing with secondary groups perms.

Could someone please shed some light on this for me?

Thanks!
Quote:breaks the potential to support multiple groups, right? This is just the primary group. Should this be changed?

No, the group permissions are already built by class_session.php using usergroup_permissions() so you have the full set of permissions for each group the user is a member of already.

The reason it's used previously is for when we're building permissions for a user other than the logged in user - we need to fetch all of their group permissions too.

Quote:Is this correct? I have moved some threads around and done some reorganization, and it seems my gids always line up but my fids don't. The board seems to run ok like this (short of the secondary permissions problems I'm having), but it's confusing me as to how this is used if it's correct. This looks like a problem to me, and would go a long way toward explaining the oddiities I'm seeing with secondary groups perms.
The fid in the array can be ignored - it's the forum ID for whatever forum the permissions are being inherited from.

It's the outer most array key which holds the forum ID - so if you've got permissions applied to a parent forum the child forum in the array will have a [fid] that matches the parent forum (or whatever forum the permissions come from).

We built the permissions fully built like this (ie, save your inherited permissions for every single forum in the cache) so that when viewing the board we don't have to do as much looping to determine which forums have custom permissions and where to inherit them from. This way we can just refernce the forum ID and fetch all built permissions for it for a particular group - think about it, you change your permissions a lot less than any visitor visits a page on your forums.

As for the permissions not functioning, the system is working as designed.

Why? When a member is apart of multiple user groups, the forum permissions need to explicitly be set for the forums you want to give them access to. Otherwise, if we inherit the permissions based on their group memberships for the particular group we're checking the forum permissions to, you won't be able to disallow access to a forum because a YES permission always overrides a NO permission and you wouldn't be able to disallow access to a group for a particular forum.

So in your example, you need to explicitly set the permissions for the "Task 1" group on the forums you wish for them to access - then it should work fine. I've just mirrored your example here with that setup and all is well.

Hope this helps,

Chris
Chris and Tiki,
Thanks for taking time to look at this. I really do appreciate it.

Chris,
I understand precisely what you are saying about just tracking the "deltas" of the permissions (inheriting most of it) to avoid chewing up a bunch of processing. I've also noticed and grown used to the "yes" > "no" mechanism.

That said, I'm still having a little trouble with this:
Chris Wrote:So in your example, you need to explicitly set the permissions for the "Task 1" group on the forums you wish for them to access - then it should work fine. I've just mirrored your example here with that setup and all is well.
I have created a Task1 usergroup and added some Registered users as secondary members of it. (They don't have to be primary do they? I hope not, as that would limit my ability to assign users - all of whom I'd like to be considered "Registered" - to multiple task-level groups.) Now, I go to the Task1 forums perms field and I remove all Registered user perms from it. (They can't even see it.) I also add all Task1 perms to it. When I log in my test user, I cannot see the forums. Sad My forum permissions are explicitly set to allow Task1 members but not just regular old Registered folks, and it appears those secondary perms aren't giving me access -- even though they've been explicitly set.

I must be doing something wrong still. Could you please clarify just a bit more?

Thanks.
Nevermind... Smile I figured out what you were saying. It's kind of tricky - and perhaps not intuitive - but it does seem to work.

Thanks!