CUNY Academic Commons

Here are the specifics of the bug report:

group is https://commons.gc.cuny.edu/groups/bmcc-open-pedagogy-seminar/
site is https://bmccopenpedagogy.commons.gc.cuny.edu/
post triggering the notification is https://bmccopenpedagogy.commons.gc.cuny.edu/2019/05/31/what-is-open-pedagogy/

Gina, when you say "I was looking at a blog post", can you please clarify the following:
1. Was "a blog post" the specific blog post linked above, or was it some other post on the site?
2. Were you looking at it on the front end https://bmccopenpedagogy.commons.gc.cuny.edu/2019/05/31/what-is-open-pedagogy/ or in the Dashboard https://bmccopenpedagogy.commons.gc.cuny.edu/wp-admin/post.php?post=9&action=edit ?

Oddly, I don't see any entries in the group activity stream https://commons.gc.cuny.edu/groups/bmcc-open-pedagogy-seminar/ that correspond to the blog post itself - I see a couple of items related to comments, but none linked to the publication of the post. (They're not in the database either.) Gina, is there a chance they were manually deleted, by you or by another group admin? These activity items are responsible for triggering email notifications, so it's important that I have a sense of this in order to piece together a story of what's happened.

Based on this, my guess is that the following happened:

1. When you were looking at the item in the Dashboard, WP saved a version of the post (a draft or something like that)
2. This triggered BP's activity creation routine
3. Because you'd deleted the old activity item, BP thought it needed to create a new one https://buddypress.trac.wordpress.org/browser/tags/4.3.0/src/bp-activity/bp-activity-functions.php?marks=3938,3940,3943-3945#L3921

I think that the behavior in 3 (and in BP itself) is probably OK. The problem here is that the activity creation routine should not have been triggered by an autosave, or indeed anytime that a user action is not involved. Ray, could you please take a few minutes to think this over, and to try reproducing? Note that this could be a Gutenberg thing.

I should note that deleting post-related activity items causes BP to think that the item has never been recorded in the stream. As such, when you delete the activity item, it'll be recreated the next time you save the edited post. It's not currently technically possible for BP to distinguish between an activity item that has been manually deleted by the user ("I don't want to see this in the activity stream") vs one that was not created for some other inadvertent reason. As such, I don't recommend deleting these activity items, as it's likely that they'll crop up again in the future in unexpected ways.

Done. See https://github.com/cuny-academic-commons/cac/commit/ac4c159de966df064a13d6dca9adafb2beb511a1

I tested the following situations:
- "Send to Group" checked for a new post -- this sent a group email as expected
- "Send to Group" unchecked for a new post -- this did not send a group email as expected
- Editing an older post that doesn't already have an activity item recorded for it -- this did not send a group email as expected

I think we should be good now.

I had to make changes to our 'send_to_group_blog' meta marker so it is saved as an integer instead of a boolean. The reason I had to do this was to make sure that our marker is always saved into the database when the "Send to Group" checkbox is unchecked.

I also had to make a change to the JS file to set the 'send_to_group_blog' to 0 when a user is editing a post:
https://github.com/cuny-academic-commons/cac/commit/ac4c159de966df064a13d6dca9adafb2beb511a1#diff-d53d8a78e5a310be3e5840e42a99bcfeL9

This is to ensure that when editing a post that the group email notification is not sent. This also means that we lose a little fidelity for our 'send_to_group_blog' marker anytime when a post is edited. If that is a concern, we could look into creating another postmeta marker just for post edits, but that might be overkill.