Port Path Access to Drupal 7

The roadmap is: let's get on a horse and ride!

Here's a first stab. I've tested it enough to verify that I can configure path access, and that my authenticated user is denied access.

https://github.com/GiantRobot/drupal-path_access is there if you like git.

Updated patch with a couple of minor issues fixed and updated docs.

Updated (adds .module file to .info, it worked fine without this but I am following the behaviour of node.module here).

subscribe

Can we get this pushed as an initial dev release?

subscribe

-_-

sub

Subscribe. Need this! :)

Subscribing

Setting more meaningful title.

The issue is flagged "needs review", you guys subscribing can participate to help make it happen. Does it work fpr you?

Please can we get a 7.x branch in git to work against?

The patch in #3 doesn't apply to the 6.x-1.x trunk

Here is a version of the patch at #3 that does apply.

I think module has a major flaw, which is that it's doing access checking in hook_init(). Access checking should be done in the menu system as hook_init() does not necessarily run on every page call (aggressive caching for example). Also, in hook_init() you are calling exit() which means that other modules don't get a chance to finish their initialization resulting in some strange display problems such as the one described in #925276: Block Styles disappear when I applied path restrictions to an unauthenticated user..

I have made the following adjustments in this D7 version of the patch.

Remove hook_init().

Use hook_menu_alter() to add our access callback. This relies on the Chain Menu Access API module, which needs to be patched with #1186208: Unable to chain in front of some system paths.

Adjust the weight of path_access module to 1001, ensuring that it is the last thing to run. This ensure that paths that are added by other modules dynamically (e.g. views page display paths) are also able to have their access checked.

Revised patch attached.

See my note in http://drupal.org/node/1186208#comment-4592362 for details about the alterations to the hook_menu_alter() implementation.

Slightly refined version of the patch, eliminates last 2 errors that I was facing.

Thanks to all who have contributed to the 7.x release. I'm back from paternity leave and have created a 7.x-1.x branch and applied the patch in #17. I've not had chance to test this though.

Moved to 7.x branch version for issue tracking.

yay!

Cool.

It will need changing a little before long though, as it looks like we'll be changing the Chan Menu Access API slightly. See #1186208: Unable to chain in front of some system paths for details.

I'm marking this as fixed, now that we have a working D7 branch.

@budda - looks like you forgot to commit the patch to git in the 7.x branch.

Forgot the push to origin :)

Cool. Can we get dev snapshots on the project page too please?

I'd added the 7.x release, but the snapshot view checkbox needed ticking.

Just tried Path Access for the first time but it kills off all the items within a certain menu - is this one of the display issues that were described above?

@dixhuit - you are correct, as the D7 version is now implementing the access control in a more standard way (through menu_alter). You can use the Always Visible module to get menu items to display regardless of the access permissions:

http://drupal.org/sandbox/mthomas/1119418

I meant that it actually removed the menu items from the menu (rather than simply not displaying them). I also noticed that certain items were missing from my admin menu. I've had to roll back to a previous db dump.

@dixhuit - It does not remove any menu items. If you don't have permission to view a page, then you will not see it in the menu. That goes for viewing the menu as well as editing it.

Ahh, I see. Sounds like the 'Always Visible' module needs to be rolled in to Path Access.

I'm not convinced that the Always Active module should be rolled into this module as the fact that the menu items are hidden when users dont have permission to access them is standard Drupal behavior. The functionality provided by the Always Active module is applicable to any and all access modules, so it would be better as a standalone project.

It would be good to see hat module released outside of the sandbox that it's currently in, and would also not be a bad idea to point people towards it on the project page of this module.

I did put the question to Matt Thomas (see #1186172: module release) but have not yet had a response.

I was unable to see menu items (even in config) even as user 1. That seems a little excessive to me.

Marking this as fixed since we now have a D7 git branch and working D7 version. D7 issues can be opened against the D7 tree.