[buddypress-trac] [BuddyPress Trac] #6094: Support custom group statuses

buddypress-trac noreply at wordpress.org
Fri Jan 9 15:11:24 UTC 2015


#6094: Support custom group statuses
-------------------------------------------+-----------------------------
 Reporter:  Offereins                      |       Owner:
     Type:  task                           |      Status:  new
 Priority:  normal                         |   Milestone:  Future Release
Component:  Groups                         |     Version:  2.1
 Severity:  normal                         |  Resolution:
 Keywords:  reporter-feedback needs-patch  |
-------------------------------------------+-----------------------------
Changes (by boonebgorges):

 * keywords:  reporter-feedback => reporter-feedback needs-patch
 * type:  enhancement => task
 * milestone:  Awaiting Review => Future Release


Comment:

 Offereins - Thanks for the ticket. Related: #4119, #1125.

 I agree that the current state of group statuses is an unholy mess, and I
 am 100% in support of cleaning it up.

 I'm pretty sure I wrote the `@todo` you refer to, and my thinking is much
 along the lines of what dcavins has laid out above. Our group statuses are
 actually shorthand for bundles of related functionality:

 Public: can be viewed in directories; can be joined by anyone without
 membership request; content can be viewed by anyone
 Private: can be viewed in directories; can be joined by invitation; can be
 joined by membership request; content (aside from home page) is only
 visible to members
 Private: cannot be viewed in directories; cannot be accessed by URL except
 if you are a member; can be joined by invitation; cannot be joined by
 membership request; content is not visible to non-members

 Ideally, we would first abstract out all of these pieces of functionality
 (I think it breaks down to four or five different traits, plus perhaps
 some of the additional items dcavins has listed above - though I think
 those, strictly speaking, would be enhancements to the current setup).
 Each of the "traits" or "properties" or whatever would then be separately
 configurable, at least in code. Then, group 'status' would be internally
 parsed as shorthand for the bundles of properties listed above. (Think
 about, eg, what happens when you set 'public=true' in
 `register_post_type()`.) Once this happens, we can have a central location
 for filtering the list of available group statuses - and maybe even
 introduce something like `bp_register_group_status()`, like the new
 `bp_register_member_type()`.

 This is all pretty complicated, and will have to be accompanied by copious
 unit tests, but it's a mountain we can climb! Let's see what we can do
 over the next few releases.

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


More information about the buddypress-trac mailing list