Control posting rights for comments/replies in D5

Please follow the directions that were shown when you posted this issue. What node type is the leaked post?

Generally, node access depends on the cooperation of each and every module that can make the nodes available to users. The core modules are assumed to cooperate (but even core can have bugs), and any contrib modules that display nodes may or may not behave properly. If it doesn't, this would be considered a bug and need to be reported to the module's issue queue.

After I logged into the site, I was able to post responses to this same "admin" forum.

Were you able to see posts in the admin forum or just to post replies by guessing NIDs of posts in the forum?

Please note that FA 6.x is not released for production sites yet, and it may very well have bugs itself.

So through "another user account with no special access" you did not actually see posts in the admin forum, but you created comments blindly by manufacturing a reply URL, right?

i have female and male roles on my site. i have forum threads ladies only and mens only. in ladies only can just post ladies and mens only men. but when i manage the accesses with forum access, mens can post in ladies only thread an ladies in mens only thread.
it dont works :(

@Babalu: Don't hijack threads. Open your own issue.

@techgy: Yes, unfortunately this is a long-standing open issue. FA cannot really control posting rights for comments/replies. There are a few other threads about this already in the queue and it's on my to-do list.

Setting 'post comments' permissions does help, but it applies globally, not just to forums.

First of all it could help if the "reply" button was removed when there is no "post" permissions, so users could only reply by explicitely typing the reply URL. Since normal users wouldn't try that, it would prevent most users from replying. I do this in my own theme, but I'm not sure if it can be done from FA by hooking into some theming function...

@Salvis: I tried several approaches in my module and theme to hide reply buttons ans forms. Especially for forums where the answer form is on the same page as the thread.

So here's what I did on our site.I wonder how much of that could be put into the FA module:
- defined mymodule_preprocess_node() and removed the global and in-body reply node when FA denies it, just by unsetting $vars['node']->links['comment_add'] Easy to do since we have$variables['node']->tid available in preprocess_node.

- same for comments, defined preprocess_node and used sth. like

  $mynode = node_load($vars['comment']->nid);
  if (!forum_access_access($mynode->tid, 'create')) { 
    unset($variables['links']['comment_reply']); 
  }

- now the problematic case is with the answer form on the thread page. I don't see any way hacking into comment_render(), so I to create and add the form on my own. But it's not that easy because it must be done in preprocess_page and we don't get the nid there cleanly as far as I see.
So I went the other way and used hook_form. We have the nid in the comment form as $form['nid']['#value'] so we can load the node and get the tid and check access like above. If access is denied, I just set $form = NULL .
A problem remains here because node.module renders the form as box, so we still see the box title after removing the form. For removing this, I use preprocess_box and just remove titles when $content==NULL .

Especially the last step with preprocess_box is a dirty hack that I wish I could solve cleanly.

But maybe we can collect some ideas and approaches here. I think removing the answer buttons and form does help in the first case, and then it makes sense to use hook_comment to prevent storing replies. Providing the answer form and then telling the user he cannot post comments after submitting them can be a bit confusing, so I started with the visual stuff.

Thank you for picking this up, Frank!

Your approach is very interesting and maybe it can be combined with Merlin's idea (see #123152: Comment creation). From what's in that thread, setting $node->comment seems to take care of the comment form.

Blocking sneaky comment submissions in hook_comment ('validate', I assume), is a good idea. We must make sure that FA does not leave any backdoors open.

I'll be glad to review and commit a patch to FA that does this...

I don't think that Merlins apporach works. The code to render comments in node.module is this:

  if (function_exists('comment_render') && $node->comment) {
    $output .= comment_render($node, $cid);
  }

So wen can not distinguish between "no view permission" and "view permission, no post permission" here. To view comments, $node->comment must be set.

But in comment_render(), the code for deciding if we should show the edit form is

    if (user_access('post comments') 
        && node_comment_mode($nid) == COMMENT_NODE_READ_WRITE 
        && (variable_get('comment_form_location_'. $node->type, COMMENT_FORM_SEPARATE_PAGE) == 
             COMMENT_FORM_BELOW) 
        && !$reply) {

node_comment_mode uses a static variable and is read from the db, and unsetting the form location variable in the table would affect all open sessions.

So I don't see any way to fiddle with any of the nodes settings, that's why I tried the themeing way.

I might make a patch for it, including a hook_comment implementation, but don't expect that too soon. We are just in the process of launching our site. But I will come back to this!

I see, too bad. So it looks like your approach is the way to go.

I've finally been able to implement this in BETA3. Your idea of using preprocess functions was essential to reach a solution. I hit some additional obstacles, though:

The comment links have already been themed when forum_access_preprocess_comment() is called. Rather than trying to massage the HTML code, I decided to recreate (and re-theme) the links.

comment.module is very inflexible as far as permissions go. The only way I've found to get it to provide Edit/Delete functionality is to actually have the 'administer comments' permission. Also, getting access to published, sticky, comment settings, etc. on the node edit form requires the 'administer nodes' permission. I'm now temporarily assigning those permissions (on a page load basis) to enable these controls.

Please try this out and let me know what you find!

P.S. I marked the following issues as duplicates:
#123152: Comment creation
#206207: Moderators cannot delete or edit other user comments?
#163964: Mod can/can't close topic (Comment Read-Only)?

I've removed all my own fixes and still everything looks fine! Although I haven't created every possible scenario, things work fine for our site where we have different roles with special view and edit permissions for certain roles and forums.

Great work!

You've also put a lot of nice work into the GUI to explain things!

Will you also implement this in the D5 version? I'm using forum_access in D5 and I'm not able to upgrade this website to D6.

Fantastic news! Thank you!

Thanks! :-)

@DiJae:

Will you also implement this in the D5 version?

No, I won't, sorry. I'm not even sure it's possible. If anyone wants to give it a try, it's just two commits:
http://drupal.org/cvs?commit=177100
http://drupal.org/cvs?commit=185302
with the bulk of the code in the second one.

@salvis
Bad to hear that you won't implement it in D5. Why do you think it's not possible in D5?

It's not that I think it's not possible, I just don't know. I had to explore quite a bit of territory that was new to me, especially the process hooks, and I don't know whether those APIs exist in D5.

Preprocess is not available in D5 in core. If you are using Advanced Forum, all the forum preprocesses have been backported. Putting it in FA in D5 would create a dependency on AF which I'm sure salvis wouldn't want but if someone wants to write a submodule for this, you could, in theory, do it in D5 if there's nothing besides the preprocesses in the way.

Michelle

Good information, Michelle, thanks!

You're right, I think FA should continue to serve the core forum, i.e. it should be able to run the current functionality without AF. If AF is what it takes to get the new functionality into the D5 version, then an optional submodule with a dependency on AF is an interesting idea. Still, with D7 on the horizon, I would need someone else to implement and (at least initially) support this submodule.

Having the preprocess hooks would be a major help. FA needs the following ones:
hook_preprocess_forum_list
hook_preprocess_forums
hook_preprocess_box
hook_preprocess_comment

The last one is the most important one — can you really offer that one in AF?

Another obstacle is that the static variable cache in user_load() cannot be flushed in D5. FA temporarily assigns a role with administer_nodes and administer_comments permissions to the current user...

AF does all of those except box. What it does is use phptemplate_* to override the theme function and then calls a function that calls all MODULENAME_preprocess*. It does not work with doing a preprocess in the theme but works fine for modules.

You could do the same trick but be aware that would make FA incompatable with AF in D5 because of the namespace collision.

Just to be clear, I'm just offering advice on the preprocesses... I have no time to write this theoretical submodule. :)

Michelle

hook_preprocess_box() is used for the hack that Frank mentioned in #11. I haven't found a better way either, unfortunately.

I guess the hypothetical submodule could follow suit and define phptemplate_box(), but I'd be against introducing a conflict with AF.

What's your experience with claiming the phptemplate_* functions for AF?

What about doing something like

if (!function_exists('advanced_forum_whatever')) {
  function phptemplate_comment(...) {
    ...
  }
}

Coder probably wouldn't like it, but it could be effective.

The challenge with user_access() remains, though...

If you define phptemplate_box, there's no conflict with AF because AF doesn't use it.

You could check to make sure that phptemplate_* doesn't exist already but then AF won't work, which probably isn't a good solution, depending on the user.

AF and OG Forum conflict because we both claim the phptemplate_ namespace but that's the only real trouble I've had. It just comes down to the D5 theme system is very inflexible and you do the best you can. I'm glad to be almost done with it. :)

Michelle

You could check to make sure that phptemplate_* doesn't exist already but then AF won't work

Hmm, doesn't AF come before FA_plus (alphabetically as well as in real life, if we may call it that)? So AF would get the first shot at defining its functions; FA_plus could check for the presence of some AF function and if yes then rely on AF's preprocess functions, and otherwise define its own ones.

OG Forum could probably follow the same strategy.

(see you tomorrow)

AF is weighted 10 so it comes after core forum. Unless you've adjusted FA's weight, AF will come after it.

I guess the "easiest" thing to do would be:

1) Write the code as preprocesses (you can probably straight backport much of the D6 code)
2) Check if AF exists.
* If it does, the preprocess code (except box) will be called automatically because of AF's preprocess backporting.
* If it doesn't, use the phptemplate override trick to call your preprocess functions.

I put "easiest" in quotes because, franklly, this sounds like a lot of work to backport something to D5 at this late date. But, if someone wants to write it, that should, in theory, work.

Oh, and I just thought of one caveat. phptemplate_comment doesn't exist in D5. That is part of _phptemplate_variables(). The only way to get at that if AF isn't installed is to have the user put code in their _phptemplate_variables() to call it. Which is a PITA you may not want to get into. Honestly, trying to use preprocess code in D5 with forum functions is just going to be a whole lot easier if AF is installed since I already deal with all that mess.

Michelle

trying to use preprocess code in D5 with forum functions is just going to be a whole lot easier if AF is installed since I already deal with all that mess.

Yes, that makes sense. Thanks for all the brainstorming! Now, who wants to pick this up and run with it?

I'll give it a try but actually I don't know if I can handle this. I'll start with copying the recent D6 version in a D5 installation and will walk over every function and check if it runs in D5. Then I'll try to fix the preprocess problem with the preprocess workaround of the advanced forum module. Hope this will work.

@DiJae: We haven't found a solution for the user_access() problem yet: in D6 it has a third parameter that allows flushing the cached permissions, and this is critical. I don't know how to do this in D5.

Look at the two commits in #19. Those have the entire comment moderation functionality.

@salvis: Thx for the hint. The easiest solution would be to override the core user_access function in D5 with the D6 version. This would only be possible with the PECL library included (override_function). Too complicated. So I thought of copying the original D6 user_access function in the submodule for forum_access and rename it: forum_access_user_access. And then replace all usage of user_access in forum_access with the forum_access_user_access function. What do you think about that? Is this solution too naiv?

No, that won't help. What we need is to fool the comment and node core modules into thinking that the current user has the administer comments or administer nodes permission for one specific page load, so that they provide administrator features, which we then cut down to what the user is allowed to have.

@salvis: Ok, in the meantime I understood. But I didn't find a solution. The fastest thing would be to patch user_access in user.module and overwrite it with the D6 version. This should work, right?

Yes, this should work. However, it needs to "degrade gracefully," i.e. if someone updates core on a production site and forgets to re-apply the patch, we must
a) not expose any protected content,
b) not display any public error messages but silently revert to the current D5 behavior, and
c) provide some helpful message to the forum administrator about why comment moderation is not available.

This is a tall order, but FA is plumbing and it must not fail. If Coder and potx can inspect module code, it should be possible to check the number of parameters of user_access(), I guess, but this will be more work beyond just getting it to work. The result of the check probably ought to be cached, so that the check doesn't need to be repeated for every page load.

I don't know whether we've identified all the missing pieces yet...

I'm still working on a D5 version. Because of missing time the recent version depends von Advanced Forum and it's working fine with the preprocess workaround. I also patched the user.module because of the user_access function. There is another problem: Caching of menu items in D5. In comment.module(D5) the menu item to delete comments (hook_menu) stands in the may_cache conditional and is cached. Therefore the deletion of comments does not work also the link to delete comments is shown. The menu item has to been put in !may_cache. This problem does not exist in D6 because menu items are not longer cached.

Having a dependency on Advanced Forum is fine as long as you package your code into a separate optional add-on module, so that the existing functionality remains available without AF.

So you need a patch for comment.module, too...

yes, comment.module needs to be patched. But in the moment it seems that the whole thing is working. As soon as I have enough time I'll make a package for D5 users to use the forum_access functionality in D5. But it can take some time because I'm just working on a big project...

Subscribing