[buddypress-trac] [BuddyPress Trac] #6677: Groups: Draft, Locked or Suspended status

[buddypress-trac]

#6677: Groups: Draft, Locked or Suspended status
------------------------------------+-----------------------------
 Reporter:  dcavins                 |       Owner:  dcavins
     Type:  enhancement             |      Status:  assigned
 Priority:  normal                  |   Milestone:  Future Release
Component:  Groups                  |     Version:  2.6.1.1
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-feedback  |
------------------------------------+-----------------------------
Changes (by dcavins):

 * owner:   => dcavins
 * status:  new => assigned


Comment:

 Replying to [comment:10 imath]:
 Thanks, @imath, for your thoughtful comments. I'll take a look at the post
 status approach and see how it can help. I started originally working with
 the WP user roles/capabilities model because it's built to be extended,
 but I'm also somewhat familiar with it. So thanks for the suggestion for
 another inspiration.

 Also, don't get hung up on the term "capabilities."  I think your
 suggestion of "properties" is the right term, but the point is that
 certain group statuses convey allowances to group/user interactions, no
 matter what those things are called.

 > eg: `bp_groups_user_can( $user_id, 'join_group', array( 'group' =>
 $group ) )`
 Yes, much of what we need to check is user-specific, so making those items
 a `bp_user_can()` check is a great idea.

 > Finally i'm not sure to understand what the status property of the group
 became. IMHO $group->status should always return the "id " of the status
 eg: public, private, hidden or whatever and then we can get the detailed
 properties of this status by using the global group status object, no ?
 Meaning if a plugin do stuff with this status it should still work? Why
 would we need to check the BuddyPress version ?
 My concern is that if one plugin registers a custom group status, but
 another plugin is checking by legacy status (public, private or hidden)
 then the logic in the second plugin falls apart for groups that have a
 custom status. Basically, once group status properties are in place,
 plugins need to check the property they care about rather than checking
 the status. Like checking for the user capability `edit_others_posts`
 instead of user role of `editor`.

 >
 > FYI there's a var_dump in src/bp-groups/bp-groups-template.php at line
 3196 of your patch
 Thanks!

 I also have come up with a plan to fix the problem of orphaned custom
 statuses, again using the user roles model for guidance. So instead of
 registering custom statuses on every page load, you'd register your custom
 status once on plugin activation and it'd be stored. I was trying to avoid
 that, but it makes for much more reliable behavior. (For instance, if you
 perform an action that deregisters a custom status, we could at that time
 switch the groups that have that status to that status's legacy fallback.)

 I'll work on another iteration of this patch next week.

 Thanks again!

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