wrong permission for admin/structure/menu/parents

Er, no. Unless we can track this down to something pervasive in the system, this is just normal.

Can anyone reproduce this?

access arguments for admin/structure/menu/parents is set to array(TRUE), which is no permission to be granted by user_access, so that returns access denied by anyone but user 1.

Getting a JSON-file looks correct to me.

This patch sets the permission to administer menu, the same as the other menu items at admin/structure/menu/*

edit:
sorry, crosspost.
I'm not sure why it had TRUE as a permission though, was it just a mistake, or is it there intentionally?

And this is normal as it doesn't prevent usage of anything really, just allows an administrator to select a default parent item that's not in one of the selected menus on admin/structure/types/manage/page (under Menu Settings).

To reproduce, just visit admin/structure/types/manage/page and view the menu settings. The error then shows up in the log.

D8 first. Let's get these fixed on D8 and into D7.

D8 roll.

Would be good to write a test.

I had a couple of log entries that revealed this same behavior (Top 'access denied' errors ), but the site is on D7 not D8. As stated above I go to the URL and all I get is the double brackets. Just an FYI - perhaps this issue is a legacy from D7?

returning your posts to D8

@cperg We fix first all bugs in D8 and then we backport the solution to D7, this is our normal process.

it was just a heads up - didn't expect your process to be different from what you stated.

sub

Note - steps to reproduce the bug in the UI:

1. Log out of any user 1 account
2. Log into a superadmin user account with access to everything
3. Start on admin/structure/types/add
4. Click the "Menu settings" vertical tab
5. Check and uncheck "available menus" at random
6. Note that the "default parent item" does not update
7. Check chrome/firebug network tab and note ajax requests to admin/structure/menu/parents all return 403 Access Denied

Added a failing test for this: https://skitch.com/e-alanevans/8q2du/test-result-testd85.localhost

Test result after patching: https://skitch.com/e-alanevans/8q2ry/test-result-testd85.localhost ... https://skitch.com/e-alanevans/8q2rb/test-result-testd85.localhost

Patch including test attached. Leaving in review for now - the test itself needs review, and I'm not 100% sure that "administer menu" is the correct permission for this: The feature only shows up on a node type creation form, so in the sense of the items returned by the callback it's related to menu admin, and in the sense of where the data is used, it's only related to node type admin. To make this callback useful, you first need access to create new content types, and to see the menu items you also need permission to view all those menu items (which is only guaranteed for menu admin).

On the other hand, maybe the only reasonable permission for the data returned by the callback itself is menu admin, as menu admins are the only users who should be able to see all menu items.

April 1 2012
Yes I am running into this all the time in Drupal 7.12, it prevents the use of some Node References and prevents the use of .

I have Page, Article, Event, Contact, Date and Test2 Content Types.
I have 2 views for Contacts which display first name only and full name. These show as drop down fields in the Event form but no selection is entered into the database, content type or view.

With "Content types that can be referenced", Page and Article work ok, but any other created Content Types do not work.

A further problem is that some Content types do not display in the selector, this too produces error message. The Content type is selectable from a user menu however.

Changing the version back to 7.x makes this less rather than more likely to get fixed, see http://drupal.org/node/767608

Not sure about the permissions either, should it be administer node types + menu admin?

Not sure about the permissions either, should it be administer node types + menu admin?

This kind of javascript could be be used by other modules so i would think that just "administer menu" is enough.

Makes sense - using just "administer menu" keeps this callback decoupled from where it's used, so that the permission just expresses the level of access that you should have in order to view all of the data that it returns. Although it's only used in one place that we know of, there is potential for it to be used elsewhere.

+1 then for keeping "administer menu"

#16: 849624-menu-parents-access.patch queued for re-testing.

Retesting against latest HEAD since it has been over a year.

reroll of patch from 16 against 8.x - moved test into MenuTest.php. that test passed when i tried the patch on a local install.

+++ b/core/modules/menu/lib/Drupal/menu/Tests/MenuTest.phpundefined
@@ -673,4 +673,16 @@ private function verifyAccess($response = 200, $menu_name = 'tools') {
+  function testMenuParentsJsAccess() {

This should be marked as public. Additional we should check that a user without the permission does not have access

redid patch against latest 8.x, and added 'public' to this patch's test function. i didn't change the other plain 'function' declarations in MenuTest.php, that seemed out of scope. i also added some lines to check for a 403 return to an unprivileged standard user. Alan or someone with more experience with writing tests should probably review that code. it worked when i tried it on a local install.

Thank you!

This issue was RTBC and passing tests on July 1, the beginning of API freeze.

Committed/pushed to 8.x.

Moving to 7.x for backport.

@mikeytown2 has the start of a patch in #1633130: Path admin/structure/menu/parents returns 403 unless UID=1 (which I closed as a duplicate), but the test isn't backported yet.

How is it that this still hasn't been applied to 7.x? Every time I update core I have to go and manually patch the menu module on each of my 50+ drupal sites. Annoying.

Because instead of uploading a D7 patch for review, which could then be RTBCed and committed, people keep manually patching menu module on their D7 sites. :)

#32 Well, patch mentioned in #30 seems to be working fine. Maybe it would be way to go?

added instructions for doing a backport.

Backported #26 to D7.

Patch looks good +1 for RTBC.

For any potential reviewers: steps to reproduce the issue are in #15.

I know I normally shouldn't do this to my own patch, but we had one person RTBC it. I think that's all the RTBCing it's going to get.

Committed to 7.x - thanks!