[buddypress-trac] [BuddyPress Trac] #6210: Create New Invitations API
buddypress-trac
noreply at wordpress.org
Mon Mar 11 21:03:46 UTC 2019
#6210: Create New Invitations API
-----------------------------------------+-----------------------
Reporter: dcavins | Owner: dcavins
Type: enhancement | Status: reopened
Priority: low | Milestone:
Component: Core | Version:
Severity: normal | Resolution:
Keywords: dev-feedback trac-tidy-2018 |
-----------------------------------------+-----------------------
Comment (by boonebgorges):
> I'm not using component_action at the moment for group invitations, but
added it for flexibility
I figured as much. I wonder if it might be more transparent (though less
BP-ish?) to simply have a `type` column. `group_member` would be one type.
`account` might be another type. `site_membership` (ie a role on a WP site
in a MS network) might be another. Then, do away with the `component`
columns. They'd still be registered within components - so `bp-
groups/classes/...` and so on - but without the conceptual overhead of
`name` and `action`, which almost-but-not-quite fits here.
> This seems like an edge-case use to me, though, since you could work
directly with the invitations object class to do mass deletions, for
instance.
Yeah, let's go with `abstract`. Someone doing this kind of thing ought to
have to set up their own extending class, as a way of making intentional
that they want certain actions to no-op.
> I agree with you that making a clean break where we have to is probably
better than creating a situation where it fails occasionally, and
frustratingly.
Agree 100%. Let's make sure that these breaks are properly documented,
along with some suggestions about how to migrate to the new system.
Speaking of migration, we'll soon have to discuss how migration will work.
--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/6210#comment:27>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac
More information about the buddypress-trac
mailing list