I just noticed that allowing the 'authenticated user'-role access to edit some menus doesn't have any effect.

CommentFileSizeAuthor
#2 menu_stp-288727-2.patch1.18 KBegfrith
#1 menu_stp_authenticated_user.patch459 byteswotsoft

Comments

wotsoft’s picture

wotsoft commented
Status: Active » Needs review
StatusFileSize
new menu_stp_authenticated_user.patch459 bytes

I had the same problem.
I found the problem in the code and wrote a patch.
Check it out!!!

egfrith’s picture

egfrith commented
Priority: Minor » Normal
StatusFileSize
new menu_stp-288727-2.patch1.18 KB

Ooops. I have solved this issue independently at #288727: Menu settings do not show for the authenticated user role, having overlooked this bug. However, to keep the bug discussion together, I'll post my patch here. It follows the same principle as the one here, but is in my view neater, reducing the code count significantly:

I can confirm that the module does not work when the "authenticated user" role is used to designate the subtree. The problem is that the module was assuming that the information about roles is kept in the users_roles tables. This is not true for the authenticated user role. Instead, as demonstrated at http://api.drupal.org/api/function/user_access/5 , the information is already cached in the $user object.

The attached patch obtains the role ids in _menu_stp_alter_node_edit_form() by from array_keys($user->roles) . The function _menu_stp_user_roles() is deleted, as it only appears in _menu_stp_alter_node_edit_form() and it only requires one extra line in _menu_stp_alter_node_edit_form() .