2007-03-01, 08:26 PM
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®), 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.
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:
Why is this last line shown above not equal to
(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:
That all makes sense to me. But after those initial few, I start getting mismatches:
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!
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®), 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.
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!