[buddypress-trac] [BuddyPress Trac] #7176: Implement user capabilities for Activity component

[buddypress-trac]

#7176: Implement user capabilities for Activity component
-------------------------+-----------------------------
 Reporter:  DJPaul       |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Future Release
Component:  Activity     |     Version:
 Severity:  normal       |  Resolution:
 Keywords:               |
-------------------------+-----------------------------

Comment (by boonebgorges):

 Hi @johnjamesjacoby - Thanks for your thoughts. Your point-by-point
 defense of WP's roles API is noble :) I think we're in agreement that
 mirroring WP's system directly - especially the storage of role
 definitions in site-specific options table - is something we want to
 avoid.

 Your ideas about fine-grained, highly configurable, component-specific
 roles are very cool, and I think are good as a long-term vision. The one
 part I don't understand conceptually is the component-specific capability
 methods - `bp()->activity->current_user_can()`. This only seems valuable
 if the following two statement both make sense and could return different
 values:

 {{{
 bp()->activity->current_user_can( 'edit_activity', $activity_id );
 bp()->notifications->current_user_can( 'edit_activity', $activity_id );
 }}}

 It seems to me that the second one doesn't really make sense. The
 "namespacing" - the separation of concerns by component - is inherent in
 the fact that different capabilities (`edit_activity` vs
 `edit_notification`, etc) are registered by, and specific to, their
 components. Developers are not interested in whether a given component
 says that a user can perform a certain action, they are interested in
 whether a user can perform a certain action, period, and behind the scenes
 the component is responsible for answering the question.

 In some cases, multiple components will be involved. I'm envisioning
 something like this:

 {{{
 // in bp-activity
 function bp_activity_map_meta_caps( ... ) {
     // ...
     switch ( $cap ) {
         case 'edit_activity' :
             // checks that are specific to the activity component
         break;
     }

     return apply_filters( 'bp_activity_map_meta_caps', ... );
 }

 // in bp-groups - this is separate from the main meta-cap-mapper
 function bp_groups_map_activity_meta_caps( ... ) {
     switch ( $cap ) {
         case 'edit_activity' :
             if ( this is a group activity ) {
                 override or append the default caps based on group
 permissions
             }
         break;
     }

     return ....
 }
 add_filter( 'bp_activity_map_meta_caps',
 'bp_groups_map_activity_meta_caps', 10, 4 );
 }}}

 In this way, `bp_current_user_can( 'edit_activity', $activity_id )` will
 be pretty simple for developers. But behind the scenes, individual
 components will be responsible for managing caps.

 I like the future of fine-grained, configurable roles. For the time being,
 I want to be sure we pick an infrastructure that lends itself to this kind
 of thing being built in a plugin, a process that'll become progressively
 easier as we make our system more sophisticated. I think that a minimum
 first version will involve two roles that are more or less hardcoded: one
 role containing the primitive caps that correspond to a regular logged-in
 user, and one containing all primitive caps (corresponds to
 `bp_moderate`). Roles will then be filterable. As for user-role
 assignment, I'd argue that for development, we can hardcode this: the
 users with `manage_options`/`manage_network_options` get admin role, while
 everyone else gets the "normal user" role. Functionally, this is identical
 to how we currently handle the `bp_moderate` cap, and I think it's a good
 starting point. This can also be filterable.

 Does this sound like a good approach for the time being?

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/7176#comment:11>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac