CUNY Academic Commons

Well, yes -- my issue was that someone hit reply and it went to the CUNYCommons address. Is that expected behavior? It seems like we should have some way of notifying people that the message they thought they were sending to someone did not reach the intended recipient. Perhaps that's best handled by an email rule in Outlook.

But i think it's understandable that a user would reply to a notification, since RBE allows for that for forum posts. So perhaps we can more clearly signal that people shouldn't reply to email notifications of blog posts?

Steve's message seemed to suggest to me that the comment was also posted on the blog post itself. that could not have been through the email reply, right?

The original blog post is here: https://spr17urbanedhistorycourse.commons.gc.cuny.edu/2017/06/03/class-is-over-but/ The email reply did not post there as a comment, though I imagine that this was the goal of the person who hit Reply in her email client.

I thought that RBE handled these cases:
a. the blog post is on a site associated with a group
b. as such, the activity item generated by the blog post is associated with the group
c. BPGES handles the outgoing email according to group-member subscription levels
d. RBE should catch all outgoing GES emails and modify the Reply-To header

It appears that a-c worked properly, but not d. I'm guessing this is because RBE is not network activated, so that when the item was originally posted, it was on a site where RBE's filters were not set up.

Ray - Have we ever had RBE network-activated? Are there reasons not to do it? Another possible solution: non-root blogs should post their activity items to BuddyPress via a REST API ping to the root blog, rather than via a PHP filter from network-activated BP. This may serve as an interesting proof-of-concept for an improvement to BP, but it's more complicated than simply network-activating RBE :)

It seems like we should have some way of notifying people that the message they thought they were sending to someone did not reach the intended recipient

RBE does warn people when they reply to an email notification that doesn't support RBE-replies, but that didn't kick in in this case because RBE wasn't enabled on the secondary site. It may be a decent idea for the default (non-RBE) Reply-To to be a non-functional email address (noreply...), which would do nothing but return an error response. On the flip side, I assume that some valuable support instances have come from people responding to email notifications, so that's worth thinking about as well.

Thanks for your rundown, Boone. Your analysis is correct.

Have we ever had RBE network-activated?

We never have, but I guess it makes sense to do so in the context of groupblog items, and especially since the RBE email bounce handler introduced in #6674 requires RBE to be active.

The only other issue I see is if someone has bbPress active on a sub-site, since RBE is not currently compatible in multisite environments. Basically the site ID would need to be added to the RBE querystring and switch_to_blog() would need to be used when parsing the email.

If this is important to be addressed in a point release, I can work on this.

Basically the site ID would need to be added to the RBE querystring and switch_to_blog() would need to be used when parsing the email.

Can't it be handled via the activity item? A comment on the activity item should sync back to the blog post (your BuddyPress handiwork).

Either way, my impression is that this is not hugely important for a point release, especially if it'd take a fair amount of work to adapt. Do some initial investigation, and if it looks like it's more than a trivial fix, let's put it in Future Release and think about it as part of a broader think about the way content syndicates across a BP network.

It seems wise to make some (non-code) decisions about how to handle non-RBE Reply-To. The status quo is that replies go to cunycommons@gmail.com, which may serve some purpose but also could create confusion, as in this case. A dedicated noreply address could be configured to autorespond with an error message, but adds another level of complication for people who need support and expect to be able to get it by hitting Reply. Matt, do you have thoughts about this?

Well, I would say that I agree that getting these emails helps us address errors. Perhaps we should set the reply-to to our zendesk account ( support@cunycommons.zendesk.com ), though, so that Marilyn could handle communication with users and issues that should be raised to tickets.

I've added Marilyn as a watcher here so that she is aware of this

Can't it be handled via the activity item?

It's possible, but only for groupblog items. bbPress (and potentially other plugins) would still require the site ID since that information isn't always available in the activity item.

Perhaps we should set the reply-to to our zendesk account ( support@cunycommons.zendesk.com ), though, so that Marilyn could handle communication with users and issues that should be raised to tickets.

IMO this is the easiest fix for the foreseeable future.

It's possible, but only for groupblog items. bbPress (and potentially other plugins) would still require the site ID since that information isn't always available in the activity item.

Ah right, I was thinking only about groupblog items. But I guess even with blog posts there are complications: non-group-linked blogs will (I think) only generate activity items if they are public, which will result in an inconsistent experience, since you won't be able to comment on private blogs via email.

IIRC, RBE adds a header to outgoing emails that don't support email replies, informing the user that replying to the email will do nothing. Maybe we can add something similar for non-RBE sites?

Yes, please do add the Zendesk address. Thanks!

Ray, would you mind making that change? I think we can filter the Reply-To header without modifying the From address (or the network admin email address), but you probably know this much better than I do :)

thank you, Ray

Ray, did you have a chance to look into this (a network-wide listener for RBE)? If not, please bump from the release.

Hi Ray - Do you think this is a potential quick-win for 1.13?

I think this is doable for groupblog post items, but we have to make some decisions here.

The BP Groupblog plugin currently only records new blog posts into the group activity stream. In order for RBE to work for group blog posts, we would also need to start recording blog comments into the group activity stream. Do we want to do that? I'm guessing we do.

As Boone mentioned above, BuddyPress has a blog activity sync routine, but we probably will not be able to use this because BP Groupblog sets different activity identifiers (activity component is set to groups, the type to new_groupblog_post, the primary id to the group ID). Will probably have to write manual code for this the way BP Groupblog currently does for groupblog posts.

Secondly, I would need to modify RBE so group users can reply to groupblog posts and comments. I would probably lift most of the code I wrote for the BP Docs RBE module here, so this shouldn't be too hard.

The BP Groupblog plugin currently only records new blog posts into the group activity stream. In order for RBE to work for group blog posts, we would also need to start recording blog comments into the group activity stream. Do we want to do that? I'm guessing we do.

Yeah, I think this is probably worth doing.

A tour de force! Everything seems to work beautifully, as advertised.

One observation. When a new post is created on a groupblog, the subject line of the generated email is of the form:

([group name]) Blog Post - [post name]

When a new comment is created, the subject line is of the form:

([blog name]) Re: Blog Post - [post name]

The text in parentheses at the beginning should probably be consistent: either the group name or the blog name. Probably the blog name is slightly more appropriate, but I could go either way.

([blog name]) Re: Blog Post - [post name]

Ahh, good catch! I think group name might be better, just to stay consistent with other group emails.

I'll make this change.