Custom Menu Permissions

Module Overview

This module does two things:

It allows for the permission used to access any menu item on the system to be overridden.
It allows for custom permissions (see hook_permission()) to be created through the admin interface. These permissions can be used the same as any permissions created in a module using hook_permission() - ie in modules, templates, and in hook_menu() callbacks.

Often in Drupal, the developers re-use permissions for menu paths. An example is the 'Administer blocks' permission, which allows users to administer blocks (admin/structure/block), create new blocks (admin/structure/block/add), configure blocks (admin/structure/block/manage/%/%), and delete blocks (admin/structure/block/manage/%/%/delete). Developers however may want to give permission to move blocks around on the block admin page(s), but not create/edit/or delete blocks. This is not possible with core, as all of these paths use the same permission, not allowing for fine-tuning of access to these pages.

Using this module, a user can override the access arguments for any menu path registered in the system, setting the access arguments to a custom permission. This means that separate access arguments can be used for any/all of the paths listed above, and indeed for any path in the system.

In order to allow for more flexibility, the module allows for custom access arguments to be created through the admin interface, which will then appear on the Permissions page, and can be assigned to roles.

Note

The default menu access function in Drupal is user_access(). This means that when a user attempts to access a page, the system looks to see if the user is member of a role with the given permission before giving access. However, not all menu paths in Drupal use user_access(), many create their own custom access callback (function). When the permission for a menu path is overridden with a new permission by using this module, the access callback for that menu path is overridden and user_access() is used instead. This generally shouldn't be a problem, since this is the behavior you likely want, but it could create some funny behaviors for some paths, depending on what the developer has done in the custom access callback.

As such, when viewing the module configuration page, there is a column listing the original access argument for each menu path. For any menu paths that do not use user_access() as their access callback, the text 'Original callback doesn't use user_access()' is shown. If you set a custom access permission for these paths, make sure to test the path thoroughly with different roles, to ensure that the resulting behavior is as you want it to be.

Installation

Install the module as according to all Drupal modules

Configuration

The configuration page is at Administer -> Configure -> System -> Custom menu permissions (admin/config/system/custom_menu_perms). If you need to create new permissions, you can use the 'Add new permission' tab on that page.

To reset a permission back to its original callback and value, choose 'default' for that permission, and save the page.

Related modules

Custom Permissions - this module appears to do much the same thing. Try them both to see which one best meets your needs.

Menu per role - this module provides a solution for D6, though it doesn't actually block access to the pages, it just provides a method of hiding menu items from menus.

Menu admin per menu - this module allows for administrators to be set for specific menus.