[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