All menu items are displayed without regard to access rights

Use menu.default_tree_manipulators for access checks of links and do not build links which don't have explicitly granted access.

menu.default_tree_manipulators

is a Core utility service that provides methods for manipulating menu trees, see \Drupal\Core\Menu\DefaultMenuLinkTreeManipulators.

While it's somewhat related, this also applies to unpublished nodes as well.

I found this Issue after I made my own very simple solution (only the last line of following code):

function template_preprocess_we_megamenu_ul(array &$vars) {
  $data_config = $vars['data_config'];
  foreach ($vars['items'] as $key_li => $li) {

    $vars['href'] = '';
    if ($li['url'] == '<front>') {
      $vars['attributes']['data-id'] = 'home';
      $vars['href'] = Drupal::url('<front>');
    }
    else {
      ...
    }

    // here we check the user access 
    if (Url::fromUri('internal:' . $vars['href'])->access() == FALSE) continue;
   ...

Seems to be fine... What you think?

Is this project [we_megamenu] still maintained?

Thanks, #7. Thanks for your solution, we need to check internal link first ;)

@lexsoft, we still working on this project...

Patch: menu-items-access-check-2998479-2.patch works for me! Thank-you!

@sassafrass, does version 1.5.0 of this module, without menu-items-access-check-2998479-2.patch, fix your problem?

I tried #2 but it seems the lines were slightly off on the latest release, 8.x-1.5. This is my first official patch submission, so hope it works for those who need it. All seems fine in my testing.

Edit to this one. Not sure how but applying the same #2 patch worked just fine today compared to yesterday. Same command, folder, etc. Please disregard my patch #14 as #2 works as expected now.

Did this patch make its way into 8.x-1.7?

An updated patch for 8.x-1.7

I have a problem with this, and it's not the patch, but the way that the module has always worked, at least as far as I can tell.

The issue I have is that, when I'm user 0, I want to configure ALL of the menu options, such as Font Awesome icons. But even in the admin configuration screen, the menu is curated based on access. So for menu items created by Views, with specific role access, I am unable to configure the menu item without editing the DB object itself. This is very error prone, and not a long-term option.

The attached patch builds on the patch above, but adds in the idea that, if you are in the back-end, you will see every menu option, regardless of access. This will allow you to configure every menu option, even those that user 0 might be unable to access.

The only use case not covered here is one where a user (not user 0) is granted permission to modify a menu or to configure this module, but they should not be able to see the menu item. This is a small, low impact scenario, because even though that user would see the menu item, they will still be denied access to those pages if they try to access them. If a user has menu editing permission, seeing that a menu item exists is probably not a big risk.

I'm also changing the status to Needs Work because in theory we should add unit tests. I don't know how to test this module, but perhaps someone else can step in?

Thanks for the great module!!!

That was a fail. Somehow the patch got messed up. Here's the updated patch.

This -18 patch was working well for 5 days. Then something happened today and Mega Menu stopped using Menu Per Role. Remove Mega Menu, reloaded, and patched again. Still not using roles.

And then role control came back. Never mind.

Out of curiosity, how come this patch hasn't been added to releases?

The fix hasn't been added to the 1.10-beta. Would it be possible to add it, please?

Hello. Thank you for helping us figure out and fix this issue. Patch #18 is applied with minor changes, and the issue should now be fixed in 1.10-beta2.
1.10-beta2 also work with D9 and tested on a clean D8.8 -> D9 upgrade. More review are very welcome before we release stable version 1.10.

Thank you so much!!!

This issue has reappeared. I'm not 100% sure when it cropped up--but definitely within the last couple months. Is there a chance to reopen this?