CUNY Academic Commons

I think Matt's proposed solution (checkbox on forum postings for admins to override the email settings) could work. My biggest concern is that it would open the door for admin to override the email settings on all of their forum posts, not just announcement-types.

Putting that aside, here's a couple trickle-down things to consider:
1. This assumes that the Announcements section of groups would disappear altogether, correct? Existing announcements would need to be migrated into another area - perhaps as old forum postings.
2. The member should know that they basically can't unsubscribe from ALL communication when they're in a group. This could be accomplished by adding a line of text below 'Your email status is...' that says something like 'You may receive occasional emails from group admin that will override this status.'

I see your concern Samantha. I think that 1) it's the responsibility admins and group members to manage this, 2) we should make sure the text for the admins reminds them that they are overriding peoples' email choices as Matt's example text does.

I would also add that this functionality has to be easy to see and not a small checkbox buried somewhere.

The question of what to do with the old announcements is a good one. Can you give it another look and see if you still think converting them to forum posts is the best course?

Also good to tell people (#2) that they can't unsubscribe from all posts. Because we can't control or predict how admins will use this I would remove "occasionally" from the text and just say it straight like "Group admins can create forum posts that override these settings and send emails to everyone."

This also reminds me that we don't have a good standard way to explain UI changes to users. I'll create a separate ticket on that so we can start thinking of the best way to do that.

The question of what to do with the old announcements is a good one. Can you give it another look and see if you still think converting them to forum posts is the best course?

Took another look at this and I'm not seeing anywhere else within groups that old announcements could go. Though, while creating a test group for another ticket, I realized that adding a Forum to a group is optional, and I'm assuming Announcements are not. Therefore, Announcements are currently a channel for group leaders to contact members even if they don't have a Forum. Couldn't removing Announcements be an issue for groups that don't have forums?

Throwing this back to Matt for comment.

Prodding this to see if anyone has strong feelings about it.

As I see it, there are two options if we want to change this:

1. Announcements are removed all together, existing announcements are either grandfathered in for existing groups and remain OR they are moved into an 'announcements' post in a group's forum.
2. Announcements and forums are mutually exclusive, so if a group turns on forums, announcements disappear (I worry that would be confusing for people that manage more than one group).

• A warning is added to the user's email settings: "Group admins can create forum posts that override these settings and send emails to everyone".
• For admins, in form post creation a check box next to the text "send to all members of group regardless of email notification preferences" is added under 'topic status' (thought: would this automatically subscribe everyone to the reply posts on the forum topic as well or just the initial post by the admin?)

Regarding old announcements: It's not a problem technically to migrate them to forum posts (which would, presumably, be closed to further replies).

Bump - I want to get moving on this if we're going to do it for 1.8. Samantha's suggestion 1 sounds like the right way forward to me. If everyone agrees, I can move forward with it.

Samantha -- I'm not sure I fully understand your proposal #1 above; can you explain how it differs from what I suggested in the initial ticket post? Thanks.

Thanks. So, am I right in understanding that we are now talking about removing Announcements altogether?

Yes, that's the direction. Though after looking through all the tickets tonight, I think we should put this on hold and loop it into a small round of user testing that focuses specifically on the groups interface (related: Issue #3176) to propose the removal to users and see what they think.

I also think this would benefit from the notifications that we're discussing in issue #3501 and would have better rollout if we have that implemented first.

Just FYI on user testing, this is an admin function that many users might not be aware of; it might be something particularly to ask the Group for Group Admins about, and we might not even need to test formally -- perhaps we can consider just starting a discussion in that forum to see if people care about and use that functionality.

Having said that, I am okay with the decision if we decide to remove Announcements entirely

Sorry, just reading through this more carefully. I see that we are now removing Announcements as a special tab, and that group admins will now have the ability to force forum posts out to members, overriding email subscription preferences.

A note: in such cases where a group admin does override preferences, the notification should ideally have some text indicating that.

(thought: would this automatically subscribe everyone to the reply posts on the forum topic as well or just the initial post by the admin?)

I would say only the original post, not replies.

Sure I'd love to take a crack at this!

One question that seems unresolved from the discussion above: what about groups that have Announcements but don't have an active forum? Would the script first activate the forum and then pull in the announcements?

Also - should I worry about cleaning the database up, removing all the old announcements, or will deactivating the plugin handle that?

what about groups that have Announcements but don't have an active forum? Would the script first activate the forum and then pull in the announcements?

That's a great question! I wonder how many groups have that set-up; is there any quick way to check? In any case, yes, activating a forum and then pulling in announcements sounds reasonable to me, though let's hear what Boone thinks.

Would the script first activate the forum and then pull in the announcements?

Sounds good to me. I'd be surprised if more than one or two groups fell into this category. They'll never notice.

See https://redmine.gc.cuny.edu/issues/6695#note-5

This series of commits adds some of the basics for this ticket: https://github.com/cuny-academic-commons/cac/compare/a1cb572c6b...21e864f8ee

1. Adds the checkbox for overriding user email settings on topic creation. Note - right now it doesn't override the poster's own self-notification settings.
2. Adds a notice to the email notifications about their settings haven been temporarily overridden. All users will get this notice, not just the ones who are set to an option other than "All Email"
3. Adds a script (to run via WP CLI) that gets a list of ALL announcements, converts them into forum topics in the group (without creating activities or notifications), and then deletes them from the database if the new topic was successfully created. The announcement's date and authorship is conserved.

Let me know how this is looking!

Hi Dan - I haven't tested yet - wanted to ask a couple questions first - but it's looking great at a glance. It turns out to be simpler than I'd expected, so nice work :)

- What happens when cross-posting to multiple groups? The filter-based technique for overriding group settings suggests that forcing an announcement in one group will do the same in all cross-posted groups as well. Is that correct? Or perhaps I'm wrong, due to the async nature of cross-posting (filters wouldn't be applied on subsequent runs)? Either way, the interaction between the two is somewhat confusing. Perhaps when you check the announcement checkbox, the cross-posting interface (and functionality) could be disabled, with a message explaining that this is the case. This could use design feedback.

- Does running bbp_insert_topic() in the migration script trigger email notifications? Theoretically, this function would trigger the creation of BP activity items, which would trigger emails.

Thanks Boone!

1. I need to look into the interaction with cross-posting. I like the idea of only allowing one at a time though.
2. bbp_insert_topic() does not create activities or trigger email notifications. It's basically just a wrapper for wp_insert_post(). It's what I use in BP Multiple Forum post as well, and I need to run a separate loop to create the activity items for the cross-posted topics. You can find it in bbpress/includes/topics/functions.php. This means that it also doesn't run some of the security functions that a higher-level call does, except the sanitization that gets run in the course of bbp_parse_args.

bbp_insert_topic() does not create activities or trigger email notifications.

Gotcha - I see now that bbPress hooks its activity-creating tool to 'bbp_new_topic', which occurs in the bbp_new_topic_handler() wrapper, not in bbp_insert_topic(). Thanks!

I've added some JS to disable multi-forum posting when overriding email preferences: https://github.com/cuny-academic-commons/cac/commit/30af92d53a03e1990995377669012a0c1ee4dace

Thanks, Dan! I've had a run through, and things are mostly looking good. I had to make a mod to the migrator so that it worked with what appears to be some legacy BP data: https://github.com/cuny-academic-commons/cac/commit/eb2f6a2bf016993ab0c416e3b65063ab6f8956b6

Post dates for migrated posts still are not working for me. They're being set to the current date/time. Why not just pass 'post_date' and 'post_date_gmt' to bbp_insert_topic()? It looks like these values are passed through to wp_insert_post() (see the comment in wp_insert_post() beginning "if the post date is empty").

Oh I see! My issue is that I was assuming that since bbp_insert_topic wasn't filtering the date values explicitly that it wasn't accepting them. Here I've just pulled that logic into the main function, and it seemed to work for me. Let me know if this works!

https://github.com/cuny-academic-commons/cac/commit/8d03fc01710ab77c370a2fee89d655fa5f11eb72