Menu OTF needs its own permission

i think the "administer menu" is just right: You can wonderfully screw up your menus with this function and it shoudl only be used by experienced users. ever had a cycle in your menu? Really nice...

Maybe you have a point about "administer menu" being just right, killes. At least, it would be "just right" most of the time. But I have some use cases where a user is experienced and trustworthy enough to manage a menu item for their own nodes, but where it is not desirable for them to have access to admin/menu or admin/settings/menu. I don't know if this is a common enough need to warrant it being committed to core. Maybe if we get some more feedback, this will become clearer.

Also: I didn't know that cycles in a menu were possible. I assumed that there was validation to prevent this from happening. If there isn't, this should be filed as a separate issue, as I consider it to be a bug.

You should not be able to create a loop in the menus using the Drupal interface. You can certainly do so by editing the database. This condition could be checked when the menu tree is built, but I seriously doubt it is worth the overhead. If a user breaks their database with phpMyAdmin, let them fix it the same way.

I would like to see the permissions patch developed a little further. I don't know whether it would be deemed core-worthy, but I think it is worth trying. I could certainly make use of this permission on some sites where I want to lock the administration down.

Yes, the text on the access control page is a little vague. My first cut of text would be 'manage menu from edit post form". But that's still not good enough.

There is also now a link to "advanced settings" in the menu-otf panel. This would need to be wrapped in a check for administer menus permissions.

+1 on this.

What about naming it "create menu items"?

I'm not tempted to commit this patch yet because the setting might be somewhat uncommon. Let's evaluate this some more and see if it gets additional support.

There is another request for this feature at:
http://drupal.org/node/41296

Unlike the feature request for enabling menu_otf for only some types of nodes, this feature can't be added by a module, so it's core or bust.

On the Drupal sites that I have built, this "administer menus for own nodes" permission would be enabled and "administer menus" would be disabled for the "editor" role, which governs the permissions the site owner has. I don't want company directors having access to the full admin/menus screen!

So here's a rerolled patch.

New patch.

Dries, this feature is very badly needed. It's extremely common that we hand out 'edit own' permission but that's a local, one page change permission. The menu editing is global, affects all pages, therefore you need much more trust for it.

I agree, I created that above issue http://drupal.org/node/41296 because I am running into this problem right now with a site that is live running on 4.7 CVS. I need to be able to restrict my 'editors' from being able to edit the entire menu structure, including seeing all of the admin parts!

Right now I have a simple hack that filters this stuff out but I would certainly prefer a new permission 'create menu items' that allows users to be able to create new menu items under the specified menu but *not* have full access to the entire admin menu as well, that should only come if you have 'adminster menu' permission.

With all of the menu enhancements (bravo Richard!) this one is *badly* needed it shouldn't wait.

Ted, did you review this patch? If so, can you mark this issue "ready to be committed".

Thoroughly tested, working great! This permission is most certainly needed, two thumbs up!

Also tested - works really well!

Good on you for remembering to wrap the "edit advanced settings" link in a permissions check, Richard. As far as I can see, this patch is ready to go.

+1 from me. Im in the same situation where this permission would be desirable.

+1 from me too.

I had created the same issue and patch here: http://drupal.org/node/42949

Thanks Richard, for redirecting me!

Simon

This patch still applies to HEAD, and is still very much waiting to be committed.

This patch has been tested, applies, and needs a decision on whether Dries wants it or not.

I really need this permission for all of the sites I work on, as above, tested thoroughly, it's ready to go.

New patch for latest HEAD (old one still applies, but with offset warnings). No changes. Still waiting to be committed.

So many positive voices and since #6 everyone supports it...

yup - make sense

yes, please commit, i actually need these setting for 3 sites i have going live soon with 4.7 :-)

Here's another +1 voice. Patch looks good, let's commit!

I tested the patch again and it works like a charm. Also, it does still apply. Dries, I'd say that this feature is needed on non-community sites very much. I really hope this gets into 4.7.

We don't use 'nodes' in user output.

Isn't the "Restrict parent items to" feature adequate?

Dries, what exactly do you mean with "Restrict parent items to" feature?

Updated the patch against current HEAD. This patch is really urgent as you can't use the menu creation feature without giving users full menu administration rights.

Tested against current HEAD, still works great. I see no reason why this can't finally be committed. Can we get it in core, please?

+1 for this. For all my web design clients, I want them to just be able to modify menu items for their own nodes and not screw with the admin menu/screen. Good call.

The permission title changed to 'manage own menu items' in the last patch, which concerns me. There isn't a concept of menu item ownership in Drupal, and this patch doesn't add it.

My best idea is 'edit menu items on posts.'

Otherwise this looks like it should be ready to go.

Changed the name of the permission.

We really need help texts/descriptions for permissions. Probably these can get into the *.help files?

With the forms #access patch, this patch is now even smaller. Updated the patch and tested it. Works fine.

Bump for consideration in 6.x, this would be a really useful feature. Patch probably does not apply more.

:( patch no longer applies.

# patch -p0 < menu_otf_2.patch
patching file modules/menu/menu.module
Hunk #1 FAILED at 152.
Hunk #2 succeeded at 35 (offset -144 lines).
Hunk #3 succeeded at 707 with fuzz 2 (offset 506 lines).
Hunk #4 FAILED at 762.
2 out of 4 hunks FAILED -- saving rejects to file modules/menu/menu.module.rej

I agree this feature should be implemented into Drupal, preferably even before 6.0.

I'm right now researching how well Drupal adapts for really small sites with just a few pages, it'd actually do pretty well if it wasn't for this. I need to work around this problem for the time being, cause I don't want to learn and use yet another CMS (like Joomla) just becuase many customers want simple sites. I want to keep all options open for customization by using Drupal. ;)

I was thinking of using Taxonomy instead, but then again I'd need to find a way to make a block out of it. And using Taxonomy for this very simple purpose seems a bit confusing.

Feature requests need to go to D7. However this has been supported by that many respected core developers, that we should see it as a badly needed fix to a usability bug. Here's an untested, rerolled version.

Two years on and Dries' comments on this patch still crack me up!

Thanks Pancho... I really needed a laugh today :)

Bug or feature, whatever. Needs to be done in D7, though.

I think you can do this now with a form alter (though you might have to weight your module). Look at what menu_module does:

http://api.drupal.org/api/function/menu_form_alter/6

it's properly uses #access - so you can set that back to TRUE based on whatever condition you like.