Unprotected topics (solved - rebuild permissions), SQL Error (Solved - add 'intval()')

I've noticed this exact problem aswell.

Also, probably associated to this bug, users in the the correct access groups can't post in any of the forums, unless a moderator is assigned to that forum

zoro: I haven't seen #2.

See if 1.3 fixes the problems seen in 1? I fixed some stuff related to forum visibility (especially with moderators) but I'm not sure I've seen exactly the problem you describe.

I have the same issue:
user warning: You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near ' 1)) OR fa.tid IS NULL OR aclu.uid = 0) AND r.nid = 4 ORDER B query: SELECT t.* FROM term_node r INNER JOIN term_data t ON r.tid = t.tid INNER JOIN vocabulary v ON t.vid = v.vid LEFT JOIN forum_access fa ON t.tid = fa.tid LEFT JOIN acl acl ON acl.name = t.tid AND acl.module = 'forum_access' LEFT JOIN acl_user aclu ON aclu.acl_id = acl.acl_id AND aclu.uid = 0 WHERE ((fa.grant_view >= 1 AND fa.rid IN (, 1)) OR fa.tid IS NULL OR aclu.uid = 0) AND r.nid = 4 ORDER BY v.weight, t.weight, t.name in /var/www/drupal-5.0-rc1/includes/database.mysql.inc on line 167.

I think it only happens for regular users, not for the admin.

reverting to v5.x-1.2 causes that error message to go away.

I'm getting the same error - I disabled both the forum_access and acl modules and still getting the error when anonymous visitors access www.site.com/forum

Hi, I was getting the above SQL error, and I see it has something in common with other SQL errors (see here), that is the part that goes: IN (, 1) where the value inside the parentheses is invalid. I know very little about PHP and even less about MySQL, but after alot of fiddling, I figured out that this value is derived from the following lines of forum_access_module (in three places, I've only come across errors re two of them):

Line 66: $roles = implode(', ', array_merge(array((bool) $user->uid), array_keys($user->roles))); error here
Line 248: $roles = implode(', ', array_merge(array((bool) $user->uid), array_keys($user->roles))); dunno if it causes an error
Line 326: $roles = implode(', ', array_merge(array((bool) $account->uid), array_keys($account->roles))); error here

So, I don't know what is wrong, as I don't understand the purpose of (bool) here, nor why we are merging these two arrays. I do know that the problem SEEMS to go away (and AFAICS, the forum_access works perfectly) if I remove the (bool) from each of these three locations. This gives the following:

Line 66: $roles = implode(', ', array_merge(array($user->uid), array_keys($user->roles)));
Line 248: $roles = implode(', ', array_merge(array($user->uid), array_keys($user->roles)));
Line 326: $roles = implode(', ', array_merge(array($account->uid), array_keys($account->roles)));

So, I hope there is someone out there who can tell me why this works, when I assume the (bool) really should be in there to make sure things work properly. The module also SEEMS to run smoothly when the array_merge is replaced simply with "array_keys($user->roles)" (ie the second array being merged).

I've included my modified forum_access_module file and a patch file (if you know how to use them). If you are in need of this module quickly, and are receiving this same error, try it out, with a strong caveat emptor. Otherwise, I hope someone can figure out what the real problem is here, and give us a real patch to use.

Another note, to ethang - I was pulling my hair out (figuratively), trying to work out why my changes weren't affecting the anonymous user... the reason you are getting the same bug after disabling the problem module is probably because you, like me, had caching enabled (it's the default, I believe). If you turn off caching, reload the home page using an anonymous user, then turn caching back on, the problem should go away. I've left caching off for now on my site, as I want to see changes quickly for debugging purposes.

Caching is at http://yoursite.com/admin/settings/performance

Yikes... please don't use the patch file provided above... I confused the order of the files when using diff.exe (yes, I'm a nooB)

Also, the method I used above doesn't seem to work when defining different roles to different forums - as long as there is one role allowed, it seems to think every registered user is allowed. I think removing the $user->uid part (I still don't understand how this is related) and leaving only the $user->role (this makes sense... check the user's role, not his ID) works. So we have:

$roles = implode(', ', array_keys($user->roles));
$roles = implode(', ', array_keys($user->roles));
$roles = implode(', ', array_keys($account->roles));

for the three offending lines. Here's a patch file that should work (fingers crossed)

The (bool) is necessary to convert $user->uid to a 0 or a 1. Perhaps it needs to be intval((bool) $user->uid) -- give that a try

Yes, I've confirmed the following:

1) unprotected topics are still there - @xav - if you really meant the forums are unprotected, I don't see that. If you mean that topics (what show in the sidebar under active forum topics, etc) are unprotected, I can confirm that. This is because they are nodes, not forums. This module seems to add entries to node_access, but doesn't access those entries (AFAICS) to let us know we can't access the topic node. Please correct me if I am wrong.

2) @merlinofchaos, I can confirm the change that you made. Now it makes sense, I thought you were trying to take some values from the forum_access table which didn't exist. I've added intval to the above patch file.

3) A new bug, which I would ask permission to address here as well because I think I have a solution, is that admin are given no special rights in the function forum_access_init(), as they are in the function forum_access_db_rewrite_sql(). I've taken the following code from the latter and added to the former:

    if (user_access('administer forums')) {
      return;
    }

and now forum administrators are allowed to access all forums (otherwise the root admin is not allowed to access forums which he does not have a role for).

Please correct me if this is not proper, but I've added this to the above patch as well.

Oh, and another error in the access denied page:

• warning: array_keys() [function.array-keys]: The first argument should be an array in /home/sirimang/www/sanku/includes/menu.inc on line 1228.
• warning: Wrong parameter count for min() in /home/sirimang/www/sanku/includes/menu.inc on line 1228.

This may be normal, because normally you shouldn't get an access denied by clicking on a link (the link will just not show). But when you manually enter a forum URL which you are not allowed to see, the error comes up before saying "You are not authorized to access this page. " and the navigation and primary links are absent. Please confirm that this is not a problem only I have.

Hey, I think I figured out how to include the nodes in this module. We don't want to set permissions for each topic individually, right? We expect that each topic (node) in a forum should inherit the permissions from its respective forum, right? So, we just equate the node/# number (its "tid") with the forum/# of its parent forum, using the {forum} MySQL table (I'm learning...). We do this thus:

$tid = db_result(db_query("SELECT tid from {forum} WHERE nid = %d", arg(1)));

"arg(1)" passes on the # of the node or forum. As it stands, the function forum_access_init() only looks for pages which have the arg(0) of "forum" (meaning the URL is http://mysite.com/forum/#). Now we add another routine to the forum_access_init() function which looks for arg(0) = "node", then includes the above code to give us the new tid (that of its parent), then looks for the permissions for the parent forum using its tid as normal in the function forum_access_acces(). The routine looks like this:

  if (arg(0) == 'node' && is_numeric(arg(1))) {
    global $user;
    $tid = db_result(db_query("SELECT tid from {forum} WHERE nid = %d", arg(1)));
    if (!forum_access_access($tid, 'view')) {
      drupal_access_denied();
       module_invoke_all('exit');
       exit;
    }
  }

and the new function looks like this:

function forum_access_init() {
    if (user_access('administer forums')) {
      return;
    }
  if (arg(0) == 'forum' && is_numeric(arg(1))) {
    global $user;
    if (!forum_access_access(arg(1), 'view')) {
      drupal_access_denied();
       module_invoke_all('exit');
       exit;
    }
  }
  if (arg(0) == 'node' && is_numeric(arg(1))) {
    global $user;
    $tid = db_result(db_query("SELECT tid from {forum} WHERE nid = %d", arg(1)));
    if (!forum_access_access($tid, 'view')) {
      drupal_access_denied();
       module_invoke_all('exit');
       exit;
    }
  }
}

I've included a new patch file - NOTE: you will have to use this patch on the original forum_access.module to make it work, I think. I've tested it out, so far so good. BTW, thanks merlin, for a very useful module. I hope I'm not wrecking it.

No, something else must be wrong.

The node_access table protects the actual nodes, and forum_access protects the forums itself with some extra code. If the actual nodes are visible, there is another problem, and fixing it directly isn't the solution but is an incorrect bandaid, and won't fix things like the 'active forum topics' block.

The first thing to check: First, find a node that should be protected but isn't. Check the node_access table for *all* entries for that node. If something else is giving read access to the topic, forum access can't block it properly. You did say you thought the node_access records appeared correct.

Second, check the node_access table for records for node 0. By default Drupal comes with a single record that applies a read grant to all nodes; that *should* be removed simply by enabling the forum access module, but there may be paths (particularly in upgrade) that might cause that to not happen and if there are we need to figure out what that path is.

If you're not sure what you're looking at, paste the results of a SELECT * FROM node_access WHERE nid = X (where X is the nid of your incorrectly unprotected forum post) and I can have a look. Also paste the results of SELECT * FROM node_access WHERE nid = 0

Thanks merlin! I deleted the entry with nid of 0 in node_access and returned forum_access.module back to its original form, and all worked fine - this did cause the welcome screen to revert to a "new install" screen which told me there was no content, but once I went in and reposted my custom front page, all is well again. Except for the slight problem of still being denied access to forums as admin, because I don't have a role set. I added this code:

if (user_access('administer forums')) {
return;
}

to the function forum_access_init(), but I suppose I could just as easily give myself a role...

Thanks again, I think all is well here.

Hmm. What's interesting is that you shouldn't have had to delete that record, it should have been done for you by Drupal. Tho as I said, perhaps the upgrade made it not work quite right.

You probably want to go administer >> content management >> post settings and click 'rebuild permissions' to ensure the table is completely correct.

And yes I'll get the 'administer forums' check in as well, which should fix the admin problems.

Thanks, done. I installed forum_access after upgrading to 5.0 - if forum_access is supposed to remove node 0 on install, strange that I still had it...

Can you confirm that I was right to delete node 0? I realise that you might have simply meant to change it...

If you mean the all grant to 0 in the node_access table, yes, you were right. Rebuilding the table would've fixed it if you were wrong, anyhow.

@xav sorry, to be clear, there are two problems here:

Unprotected topics - nothing to do with this module (but maybe the module isn't doing something it should.) If the topics are unprotected rebuild the permissions or delete node_acces row 0

SQL Error - this is a genuine bug, I believe... The solution is to add 'intval()' around the phrase '(bool) $user->uid' in three places in forum_access.module.

A third problem is regarding admin not having access to protected forums by default.

2 and 3 are fixed with the file forum_access.module.2.patch found in
post #13 below.

I believe this is all fixed.

If I screwed something up please file a new issue (and reference this one) to keep things clean. There's enough going on in this issue that it's hard to track, and it's nicest when the problems are discrete.