Privileged menu items adding to BP nav for anonymous users

[DJPaul]

Privileged menu items are being added to the BP nav stack for anonymous users. For example, using turtleshell, log out, and go to a member's profile. In the navigation, you'll see Public->Edit, Public->Change Avatar, Forums->(all items), and Delete Account. Those links are malformed and, obviously, required an authenticated user with appropriate permissions to access.

Screenshot at ​http://cl.ly/image/0U1B1P3a0U1D

If anyone has any ideas why this has never shown up in BP-Default, do share. I'm wondering if the "add menu item" code needs to be wrapped in is_user_logged_in in some places, or if this is a bug or artefact of the menu walker code that I introduced a couple of weeks ago.

It's an artifact of bp-default templates. There are places in the templates themselves where we wrap bp_options_nav() (the subnav items) in if ( bp_is_my_profile() ) {}. eg ​https://buddypress.trac.wordpress.org/browser/tags/1.6.1/bp-themes/bp-default/members/single/profile.php

We should be moving the bp_is_my_profile() logic into the component classes' setup_nav() methods.

See also #4624, which is caused in part by the same issue.

(In [6519]) Only register subnav items if user has appropriate authorisation. See #4661

Just put in a first pass; turtleshell's menu now shows the same items as on BP-Default. Leaving ticket open for more improvements, including letting admins see other members' messages, and for tidy-up across components.

This seems fine enough for now. Closing as fixed. Iterate as needed.

Likely this broke the ability for super admins to edit other users profiles, since the nav items are never registered. My guess is this will need a revert/rethink.

I don't see the need to revert. Just add a current_user_can( 'bp_moderate' ) check in addition to bp_is_my_profile(). Unless I'm missing something? (haven't tested)

(In [6622]) Toggle displayed/logged-in user for sub-nav. Bail if no menu should be available. Add 'user_has_access' checks where applicable. Reverts r6519. Fixes #4661.

The actual fix was using 'user_has_access' where we needed it. I used bp_core_can_edit_settings() which is basically what you describe above, a combination of bp_is_my_profile() & moderator cap checks.

(In [6641]) Use bp_core_can_edit_settings() instead of bp_is_my_profile() in bp_get_nav_menu_items(). See #4661

This fixes a problem where the top-level Messages menu item was not
being output in bp_nav_menu(), thus promoting the child items (inbox,
sent, compose, and notices) to the top-level when viewing someone
else's user profile.