CUNY Academic Commons

Somehow, she posted it to the blog instead of to the discussion forum. Apologies.

Yeah, that person posted a blog post on the groupblog instead of in the forum.

However, this does bring up a few issues:

1. The activity item was generated by BP Groupblog.
2. RBE doesn't appear to be network-activated, which is why the RBE options were not shown.

Should I look into supporting commenting to BP Groupblog posts (similar to how we added support for BP Docs)?

I also have to ensure that there are no conflicts when using RBE network-wide.

The bleeding version of RBE supports bbPress on non-BuddyPress forums now, so a potential conflict could arise if a sub-site has bbPress activated and when someone is trying to reply to a forum post from that sub-site.

I just checked and, at the moment, bbPress is only activated on the main Commons site, so there wouldn't be an issue currently with network-activating RBE, but it could exist in the future.

• Perhaps I should look into supporting BP Groupblog posts for RBE.
• Make sure RBE will work in network-activated scenarios. (Mostly for bbPress.)

Should I look into supporting commenting to BP Groupblog posts (similar to how we added support for BP Docs)?

If you did, where would replies be posted? to the group activity feed or to the original blog post? If they would go to the original blog post, that would be cool, but if they go to the group activity feed (which may not be possible -- I think we may have turned off activity feed commenting), I guess I worry that we will confuse people.

I like the fact group blog posts show up in group activity feeds and create activity items/email notifications for group members, but I think we should center resulting conversations on the original blog post rather than moving them to the group. What do others think? (I've added a few others here as watchers)

I re-typed my response to this 10 times, because I can really see this going either way. My gut says that keeping the conversations on the original blog post is the least confusing -- it creates a clearer delineation between conversations taking place in the group forums and those taking place on a group site.

I could see it being integrated into the group activity feed if we took the time to better display conversations there (i.e. showing responses directly connected to the original comment, similar to how Facebook displays conversations in the main feed). But, taking that on seems like overkill for this specific instance.

Ray, correct me if I'm wrong, but the new activity comment/blog comment syncing stuff in BP should be able to handle most of this, right? It'd just be the groupblog stuff that'd need accounting for.

Ray, correct me if I'm wrong, but the new activity comment/blog comment syncing stuff in BP should be able to handle most of this, right? It'd just be the groupblog stuff that'd need accounting for.

Not exactly. BP has built-in support for the 'new_blog_post' type, however BP Groupblog changes this type to 'new_groupblog_post'. Currently, for the sync, BP checks explicitly for the 'new_blog_post' type. It's not filterable at the moment, so if we wanted to support comment syncing in the interim, we would have to duplicate a bunch of code from BP.

Another problem is BP Groupblog does not record groupblog post comments into the group activity stream, so BP Group Email Subscription will not be able to pick up the email and thus, BP Reply By Email will also not work.

The can of worms has been opened :)

Let's put a filter in.

Instead putting in a filter, looks like we have to make enhancements to syncing so it will support what imath did with custom post types in the activity stream. The monkey wrench is we want to modify an existing post type for use with BP Groupblog - 'new_blog_post' to 'new_groupblog_post'.

I assume that if the fix in bp-groupblog syncs blog comments to 'activity_comment' (rather than 'new_blog_comment'), then BPGES and RBE will automagically work?

I would rather go with 'new_blog_comment' (or 'new_groupblog_comment') while disabling comment syncing since that is guaranteed to be in BPGES.

At the moment, BPGES doesn't support 'activity_comment' recording effectively. Currently, there is only a check on `bp_is_groups_component()` to determine if an activity comment is being posted under a group activity update. This will not work for us.

Since activity comments are tied to the user and not groups, this makes things complicated. Perhaps we can hook into 'bp_activity_comment_posted' and look up the parent activity item. If the parent activity item is a group update and if group members are subscribed to "All Mail", BPGES can manually send these activity comments to group members. This will have to be a BPGES feature.

The monkey wrench is we want to modify an existing post type for use with BP Groupblog - 'new_blog_post' to 'new_groupblog_post'.

Ah, I see what you mean. The "existing post type" is, of course, 'post' - we'll be switching the activity type. It looks like we could probably do this by filtering 'bp_activity_get_post_type_tracking_args': if post_type = 'post' && this_is_a_groupblog_post then futz_with_the_activity_args. I guess maybe this is something that should happen in bp-groupblog, though then there'll have to be compatibility for BP < 2.2. Does that seem right?

At the moment, BPGES doesn't support 'activity_comment' recording effectively. Currently, there is only a check on `bp_is_groups_component()` to determine if an activity comment is being posted under a group activity update. This will not work for us.

Yeah, I'm not super concerned about that though. We could put a filter in GES, something like 'ass_activity_is_associated_with_a_group'. We're already making an arbitrary decision in BPGES: if ( component=groups OR (bp_is_group_component && is activity_update) ). Adding a filter to it actually makes it more structured. Then we could use this filter in the manner you suggest in the last paragraph.

Hey Ray - would you mind reviewing this conversation and giving some recommendations? It's not clear to me from the above what the best way forward is, and I want to gauge whether this improvement is feasible for 1.8. Thanks!