Closed (fixed)
Project:
Forum Access
Version:
6.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
23 Mar 2012 at 14:58 UTC
Updated:
13 Apr 2012 at 18:11 UTC
Jump to comment: Most recent file
Comments
Comment #1
salvisNormally, there is one "Forum" menu item, which is visible when at least one forum is visible and not otherwise.
Please post BEFORE and AFTER screenshots to explain what this is about.
Comment #2
Dean Reilly commentedIt might be better if I provide steps to recreate.
Say I want to create two forums called, "General Discussions" (accessible at /forum/general-discussion) and "Restricted" (accessible at /forum/restricted). General Discussions should be viewable by everyone and Restricted should only be viewable by a group of moderators.
Now I want to create a new menu which contains a link to each of these forums. The problem is that both links will show for normal users as when drupal evaluates the access callback it will return true because normal users do have access to the general discussions forum. Ideally what I would like to happen would be normal users would only see the General Discussions link where as moderators would see the General Discussions link and the Restricted forum link.
My patch changes the access callback to one which will take into account what forum the user is trying to view and return the correct value which allows the menu system to skip over those links which the user has no right to view.
Comment #3
salvisYes, that makes sense and the patch looks good, but D7 needs to go first.
Comment #4
Dean Reilly commentedI took a look at porting this patch for D7 today but found it doesn't actually require it. The forum module in D7 specifcies a second forum menu router item (forum/%forum_forum) for specific forums and containers. The auto-loader function forum_forum_load tries to load the taxonomy term and will be prevented from doing so by the forum_access_query_term_access_alter() function in forum_access. When it can't load the term the _menu_load_objects() function will cause the site to return a 404 error. This has the same effects as my patch above.
I looked into reimplementing my patch above in a way similar to D7 as a lot of the hook_query_term_access_alter code lives in the similar hook_db_rewrite_sql in Forum Access 6.x. However it feels a little backward to define an autoload function for access control when there is already a specific function to handle this. I think it may also add additional overhead to the load times as what is loaded will never be used unlike in the D7 version but I haven't run any tests to confirm this suspiscion.
Given this, I'm going to return this ticket version and status to 6.x and needs review respectively.
Comment #5
salvisThank you for the analysis and detailed explanation of the D7 situation!
On second look the docblocks in the patch need a little more love. It's cute how you split the existing block in two, but the two functions each should have their own full docblock, not just a half.
Comment #6
Dean Reilly commentedGood point, I've extended the access callback function's docblock to include a description and a reference to this issue. I've left the _forum_access_access_any_forum() docblock the same for now. Is there anything else you'd like to see in the commenting?
I made a few other changes too:
Comment #7
salvisGood changes, thanks!
You're still leaving _forum_access_access_any_forum() with only half of what it had before:
BEFORE:
AFTER:
The summary line should be something like "Helper function to determine the access to the 'forum' menu item."
And for _forum_access_forum_access_callback() something like "Access callback for the 'forum' menu path."
While you're at it, please remove the trailing spaces.
We don't really need that reference. CHANGELOG.txt and the commit message will reference the issue as usual, that should be enough.
Sorry about being so picky...
Comment #8
Dean Reilly commentedNot at all, this is the way the issue queue should work. :)
I think I got all of those changes in the latest patch. Going to change back to needs review.
Comment #10
Dean Reilly commented#8: forum_access-forum-specific-access-callback-1496402-8.patch queued for re-testing.
Comment #12
salvis#8: forum_access-forum-specific-access-callback-1496402-8.patch queued for re-testing.
Comment #13
salvisGreat, thanks, committed to the -dev version (give it up to 12h to be repackaged).
Comment #14
salvisComment #15
Dean Reilly commentedFantastic! Thanks for the help.
D