Hi fargo,
I'm copy-pasting our recent conversation here. Please confirm to this issue so that i can apply for a CVS account as stated by http://drupal.org/node/59

> Hi
>
> i've created a module to have more fine grained control on the menu
> administration.
>
> It is .. the module allows you acces control over
> * administering menu's (be able to create/delete menu's)
> * administering menu items (be able to create/delete menu items)
> * which parent menu's are available to attach nodes to.
>
> Although this module is not totally related with your menu per role
> module (which control viewing menu's) i think it could be approriate
> to merge my module into yours. I will put a copy of the menu online
> during the weekend, together with a demo-site to play with.
>
> I'm also looking into the patch to core required to get your module
> working. I *think* I might be able to remove that requirement by
> overriding some drupal hooks.

Hi!
That sounds fine.

Perhaps you have noted, I don't have as much time to look after the
module as I should have.

So I would be glad, if you could combine our modules to one and proceed
maintaining it.

However I think, it shouldbe possible to use the menu_per_role feature
("restrict view access") only without getting a performance penality by
the unused features (administer menu, items, available parents). Do you
think you could get this working?
Hm, we could also add settings to the module, which allows turning some
functionality off.

Comments

fago’s picture

confirmed :)

fago’s picture

any updates on this?

demeester_roel@drupal.org’s picture

From mid February i will invest more time in this..

robertdouglass’s picture

If you can describe your planned approach to removing the patch I want to look into this as well and can do so now.

chiddicks’s picture

I have been looking at converting this module to 6.2. The menu system has changed significantly from 5, so the patch required to menu.inc would have to change. I investigated other alternatives to this; obviously modifying core is extremely janky and should be avoided at all costs.

Here is my first thought, based on a little research. It's tricky, much more complicated than the previous version, but would not modify core:

Use hook_menu_alter to modify the access_callback of menu items, replacing the original function with a custom function included the module. The access_arguments would also be appended with an identifier for the menu item, perhaps the path of the menu item? You would only modify the MENU_NORMAL_ITEM & MENU_SUGGESTED_ITEM types, because they are the only menu items visible (although the LOCAL menu items may be fodder for further revisions, if that's something that is useful). The original access_callback would need to be stored a)to use within the new access function and b) to restore the database should the module be disabled.

This custom function would then AND the original access_callback function, run with the original access_arguments, with a set of individual permissions set through checkboxes, like the existing module uses.

Caveats: since this relies on information stored in the database, it would need to have a function for going through the database and modifying retroactively. I would also need to restore the database when the module is disabled, or else the whole menu system would be knackered.

I would appreciate some thoughts on this from someone who understands the menu system more thoroughly. I may have some time in the next two weeks to actually implement this, so don't hesitate.

mizengineer’s picture

@chiddicks - hope you do get to implement this - though I'm on Drupal 5.8. I'll be happy to test it so let me know when it's out. Thanks!

ericcorriel’s picture

subscribing

fm’s picture

any further progress?

AlexisWilke’s picture

Status: Active » Closed (won't fix)

This is now 2 years old so I'm closing it. If you can co-maintain, let us know.