[buddypress-trac] [BuddyPress] #4991: manage_options capability required for non-super admin xprofile editing

[buddypress-trac]

#4991: manage_options capability required for non-super admin xprofile editing
------------------------------------+------------------
 Reporter:  danzigism               |       Owner:
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:  1.8
Component:  XProfile                |     Version:  1.7
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-feedback  |
------------------------------------+------------------

Comment (by boonebgorges):

 > The phpDoc for that function also says that this is temporary, so I'm
 not sure what the end goal is.

 The standard treatment of caps in WP is that they are mapped to roles
 "permanently" - that is, they're stored in the database. For 1.6, we
 weren't prepared to do that, so we put in place a temporary hack. r6844
 looks like it was meant to fix a legitimate bug, but in the process it
 actually changed the implementation of `bp_moderate`.

 This is a big mess. The idea was that, in the long run, we were going to
 use real WP caps. But this hasn't materialized. So instead, we have a
 hodge-podge of `current_user_can( 'bp_moderate' )` and function-specific
 functions like `bp_core_can_edit_settings()`. Ideally (again, in the long
 run) we should pick one of these strategies and stick with it.

 For now, I think that r-a-y's patch is wise. It has two virtues: 1. it
 fixes the bug, and 2. it does so in a very specific way, using a tool
 (`bp_core_can_edit_settings()`) that we already have, instead of mucking
 around with the way that the `bp_moderate` map works.

 > Are there places where bp_current_user_can( 'bp_moderate' ) should be
 replaced with bp_core_can_edit_settings()? I can see a couple of instances
 where we could do this such as activity deletion and spamming.

 Activity deletion and spamming are not the same thing as editing other
 people's profiles, and really don't neatly fall under the rubric of
 "can_edit_settings". I think that the general strategy should be to move
 toward greater specificity/fine-grainedness with our caps, while lumping
 all this stuff under "can edit settings" is moving in the wrong direction.
 So let's hold off a larger audit for now.

-- 
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/4991#comment:3>
BuddyPress <http://buddypress.org/>
BuddyPress