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

[DJPaul]

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.

[boonebgorges]

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.

[boonebgorges]

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

[djpaul]

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

[DJPaul]

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.

[johnjamesjacoby]

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

[johnjamesjacoby]

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.

[boonebgorges]

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)

[johnjamesjacoby]

(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.

[johnjamesjacoby]

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.

[djpaul]

(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.