Issue confirmed (Screenshots aren't by 3.8.*, looks like 3.6).

System information

3.8.4-dev
Multilanguage Site (4 Lang.) & Test English (GB) Sample Data
macOS Sierra, 10.12.6
Firefox 57 (64-bit)

MAMP 4.2

• Apache-Server
• PHP 7.0.22
• MySQLi 5.6.35

  ---

  _{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/19123.}

Thank You! I was running 3.6 but wanted to report this with the latest version. Ran the update but screenshots must have been before.

I just double checked and it's the same behavior on 3.8.3 as well.

I can confirm this behaviour - to be perfectly honest I dont see how it can be fixed. For my own site where I had this I just made sure that the submenu items were set to the same access level or higher than the parent

Understood! May be forcing the sub menu item to be hidden by default (if parent == less access than available) or something like that.

This is a really major bug (imho - for MY usecases). i have a 'large' (like 40 items on 3 levels, so not out of line...) menu trees on a backend/internal application where my users have 15 different access levels to give them access to the right menu items and sub-menus.

Registered and guest is the most simple use-case, but actually, ANY menu item where the person logged on doesn't have access to the parent menu item but does have access to the sub-item, the entire menu after that item is messed up with levels all over the place. and these issues are hard to diagnose given the robust security model.

the behavior I WOULD prefer is to EITHER:

1. MY PREFERENCE: process the parent (that the user doesn't have access to) like a menu separator type so at least they can see the sub menu item under the intended menu. since its a separator, they can't click on the parent (in case it's something they shouldn't have access to). that gives them access to the menu intended AND (most importantly) doesn't mess up the menu hierarchy. This is probably the most intuitive behavior to the end user (imho). as a slight mod to this solution, you could change the parent to 'NOACCESS' to obscure it. so the user would report it hopefully and not see the NAME even of the parent menu.
2. ALSO A FINE SOLUTION and chetanmadaan's idea: Don't display the submenu item at all when the user DOES have access to the submenu unless the user also has access to every branch up the tree that the submenu is on. That is more secure (the user can't see the parent exists even though they can't click on it) and doesn't mess up the menus either. downside = it leaves the admin/user to discover why it's not displaying... which will be an FAQ i'm sure...
3. Could also display the subitem at the peer-level of the last item they DID have access to. so elevate it up a notch on the menu so it is displayed on it's own then keep track of which are level 1, 2 and 3 going forward. (sounds difficult but the most intutive).
4. I DONT THINK YOU Could display an error message when saving the subitem on administrator. The error would be that that the parent has a more restrictive access so you can't save it. I don't think this is possible because with access levels, it could be venn diagram where some users do have both, some have one some have the other.... SO I THINK it has to be handled in the menu view for the front end in one of the 3 ways above (or probably others).

I know it seems obscure, but i can't tell you how many times this has bit me when adding new menu items to my 30+ joomlas and not remembering to (researching) the access so that the menu item will display to all access levels. it would be SO much more user-friendly if this was done dynamically.

I have never contributed to the joomla code-base, but am happy to have my developer develop this change and submit it if you would want.

I have never contributed to the joomla code-base, but am happy to have my developer develop this change and submit it if you would want.

@barrycox Please do. Thanks.

Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/19123

closed as having Pull Request #24266