Skip to:
Content

BuddyPress.org

Opened 16 years ago

Closed 12 years ago

#3046 closed enhancement (no action required)

Add Proper access to members options menu items

Reported by: sbrajesh Owned by:
Priority: normal Milestone:
Component: Core Version:
Severity: normal 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 16 years ago.
just cleaning the tab alignment in earlier patch

Download all attachments as: .zip

Change History (11)

@sbrajesh
16 years ago

just cleaning the tab alignment in earlier patch

#1 @DJPaul
15 years ago

  • Milestone Awaiting Review1.3
  • Owner set to DJPaul
  • Status newassigned
  • Version 1.3

#2 @DJPaul
15 years ago

  • Resolutionfixed
  • Status assignedclosed

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

#4 @djpaul
15 years ago

  • Resolutionfixed
  • Status reopenedclosed

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

#5 @johnjamesjacoby
15 years ago

  • Resolution fixed
  • Status closedreopened

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
15 years ago

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

#7 @djpaul
15 years ago

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

#8 @DJPaul
15 years ago

  • Owner DJPaul removed
  • Status reopenedassigned

#9 @DJPaul
15 years ago

  • Milestone 1.3Future 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
12 years ago

  • Milestone Future Release
  • Resolutioninvalid
  • Severitynormal
  • Status assignedclosed

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.