Skip to:
Content

BuddyPress.org

Opened 11 years ago

Closed 11 years ago

Last modified 8 years ago

#4661 closed defect (bug) (fixed)

Privileged menu items adding to BP nav for anonymous users

Reported by: djpaul's profile DJPaul Owned by:
Milestone: 1.7 Priority: normal
Severity: normal Version:
Component: Core Keywords:
Cc:

Description

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

Change History (12)

#1 @DJPaul
11 years ago

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.

#2 @boonebgorges
11 years 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.

#3 @boonebgorges
11 years ago

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

#4 @djpaul
11 years ago

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

#5 @DJPaul
11 years ago

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.

#6 @johnjamesjacoby
11 years ago

  • Resolution set to fixed
  • Status changed from new to closed

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

#7 @johnjamesjacoby
11 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

#8 @boonebgorges
11 years ago

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)

#9 @johnjamesjacoby
11 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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

#10 @johnjamesjacoby
11 years ago

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.

#11 @djpaul
11 years ago

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

#12 @DJPaul
8 years ago

  • Component changed from Component - Any/All to Core
Note: See TracTickets for help on using tickets.