Idea: Menutree Permissions module - cascading menu-level access control by role/user ID - input needed :o)

Hello everyone,

I'm a complete newbie to writing Drupal apps and having not yet found anything which fits my needs properly, I'm setting out on writing a node access module which uses the site's primary navigation menu structure to define access permissions.

I'm still at a very early stage of planning, and the use case for the module is pretty specific, so I haven't even begun to consider all the "what-if"s associated with, say, what happens when the site admin decides to reassign the primary menu.

The closest competitor - Monster Menus - while an incredible piece of software architecture, seems to be a bit too heavily specialised, making it difficult to migrate an existing site. Also, the behaviour and complexity of the permissions system - for example, how inheritance is handled - might be a little overkill for my needs.

This is a bit of a rambling post, so bear with me... :o)

Overview of features

• Allows the owner of a node to assign permissions for the node including view, update, create child, edit menu, edit permissions, etc. Permissions are saved by mlid, and can therefore be assigned to any menu item
• The module presents a permissions fieldset in the node and menu item edit screens, allowing a user or role name to be selected, and each permission can then be individually set to allow, inherit (default) or deny
• Permissions cascade down from parent items, with the pseudo-mlid 0 starting with the default of "everyone can read" and "no-one can edit"
• A node owner gets full permissions, and their full permissions can cascade down to child pages unless permissions are reset using the "reset permissions" option

Other useful bits

• Uses pathauto to create a hierarchical URL system, e.g. foo/bar/noodle/turkey-mango, which correlates to the menu position of the node or, for nodes without a menu entry, correlates to the parent mlid's path plus /, e.g. foo/bar/noodle/turkey-mango/event/12345
• Implements a common-sense version of Menutrails which works entirely off the path
• For first-time use, nodes without an mlid use the Menutrails functionality to work out the closest parent, based on the URL. Nodes therefore inherit the permissions of the closest mlid parent (going by path). New paths are worked out based on the parent mlid (see above)
• Adds a "add child page" link/tab to the node when the current user has "create child" permission. The link will lead to node/add/?parent=; the parent $_GET value is used to select the parent menu item on the node add page
• The menutree shown in the node's menu fieldset is limited only to the nodes the user can choose as a parent (i.e. nodes they have "create child" permission on), and also lists any parents of nodes they have permission on (disabled) to show the user's position relative to the overall menu tree

Benefits

• Sensible permissions; allows the easy granting of ownership to a mini-site to an owner, who can then control sub-permissions

Drawbacks/problems

• Calculating access for each node when building a menutree might pose some performance issues for sites with many thousands of nodes on the menu tree, so it might make more sense to only calculate when hook node_access is called. That said, only the parent mlid(s)'s grants would be pulled from the DB, meaning no more than 9 (the maximum number of parents) x the number of roles the user is a member of, so it might be sensible...
• It's unlikely that storing a calculated node grant for each node/mlid, per role/user would make sense - you'd quickly have hundreds of thousands of grants, so permissions would probably be calculated on the fly
• Currently, the module expects pathauto and uses CCK to present the permissions edit fieldset (not that there's a working version of the module at the moment)
• My PHP coding, while functional, is very much not "advanced", so while I intend to cobble the module together, it's going to need some serious work to get it to a basic level of quality, I'm sure

There's plenty more, but there's some of the basics.

Sorry for all the rambling!

Alex