Skip to:
Content

BuddyPress.org

Opened 14 years ago

Closed 11 years ago

#3046 closed enhancement (no action required)

Add Proper access to members options menu items

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

Description

Hi,
As of now, we check the access of an option menu in theme and show it. For making it more uniform we can use the "user_has_access" arg while adding item, so a theme can easily use bp_get_options_nav in more effective manner.
While the message and the settings component follow it properly, other components as groups/friends/profile do not follow it.

Here is a patch for that. It will allow a theme author to use bp_get_options_nav() without checking for proper rights and will give flexibility in theme design.

Attachments (1)

bp-member-options-menu.patch (5.5 KB) - added by sbrajesh 14 years ago.
just cleaning the tab alignment in earlier patch

Download all attachments as: .zip

Change History (11)

@sbrajesh
14 years ago

just cleaning the tab alignment in earlier patch

#1 @DJPaul
14 years ago

  • Milestone changed from Awaiting Review to 1.3
  • Owner set to DJPaul
  • Status changed from new to assigned
  • Version 1.3 deleted

#2 @DJPaul
14 years ago

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

(In r 4314) Specify user_has_access param on all items added to subnav. Fixes #3046, props sbrajesh

#3 @wpmuguru
14 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

#4 @djpaul
14 years ago

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

(In [4318]) Remove duplicated user_has_access param which was added in error in r4314. Fixes #3046, props wpmuguru

#5 @johnjamesjacoby
14 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

Also, not all of these should be bp_is_my_profile(). Double check the logic here, but things like forum topics/replies are public everywhere else, so no reason not to allow other users to see the forum activity of other users.

#6 @DJPaul
14 years ago

I'm going to revert all of this and take a detailed look at each change this weekend

#7 @djpaul
14 years ago

(In [4321]) Revert all of r4314. See #3046

#8 @DJPaul
14 years ago

  • Owner DJPaul deleted
  • Status changed from reopened to assigned

#9 @DJPaul
14 years ago

  • Milestone changed from 1.3 to Future Release

In dev chat, we decided to move this to a future release because of unintended consequences with globally applying this patch, like above. sbrajesh, if you or anyone else finds that this not being fixed prevents you doing something, please clarify details.

#10 @boonebgorges
11 years ago

  • Milestone Future Release deleted
  • Resolution set to invalid
  • Severity set to normal
  • Status changed from assigned to closed

As a rule, it would be nice to use the 'user_has_access' parameter rather than putting checks into templates. But I'm not sure how much of the suggested changes are still applicable.

On that note, I'm going to close the ticket. But sbrajesh, if you still find inconsistencies, feel free to reopen with details.

Note: See TracTickets for help on using tickets.