CUNY Academic Commons

I haven't looked closely at the two systems to look for the edge cases but what you're saying seems reasonable to me. I'm assuming since the old system is opt-out and we do know what the definitely don't want to see then we can add those to the new system and set the default to subscribe.

Piggybacking on an idea that you brought up in the last meeting perhaps we could add a message when people log in about this and direct them to where they can manage their subscriptions. This would also inform everyone of the new functionality. The manage subscriptions page would also obviously have to have some explanation and instructions.

OK, I've started on a script for this, and here's what it does. I would like feedback on this, but I'm also writing for my own benefit, so I can get clear idea of what is going on.

The old system is pretty crappy and suboptimal. There are two main possible situations:
1) Forum replies. In this case, the plugin loops through each group member and checks a piece of usermeta called 'bb_favorites', which is an array of topic_ids. If the current topic_id is in the user's bb_favorites, the user gets the email.
2) New topics. In this case, the plugin loops through each group member and checks to see if they are subscribed to new topics (that's stored in a piece of usermeta keyed as gfsub_x, where x is the group_id). If yes, then the new topic_id is added to the user's bb_favorites and the email is sent.

Users can unsubscribe from specific topics, which removes the topic_id from their bb_favorites.

So that's the old system. I've written a script that does the following. I figure that bb_favorites data is not really very reliable, so I'm just skipping it (more on that in a minute). In pseudocode:
foreach group x in the system {
get all values of gfsub_x (and corresponding user_ids) from the usermeta table
foreach of these user_ids {
if gfsub_x is 'yes', subscribe them. otherwise don't
}
}
This will work fine for almost everyone. The only tricky part will be people who have actively unsubscribed to specific topics. Like I said, in the old system, unsubscribing meant removal from bb_favorites (because bb_favorites is opt-in). The new system instead assumes that most people will subscribe to everything, so has a mute list instead (opt-out). In theory, I could pull up a list of every forum topic ever started for a given group, compare that list of topic ids against each member's bb_favorites, and infer the mute list from those topics missing from bb_favorites. But lots could go wrong: the original bb_favorites data could be messed up (which, as a quick glance at the database suggests, it totally is); forums could have been deleted; people could have left groups; etc.

My take: There will be very few cases in which an individual has actively unsubscribed from a topic at some point in the last few years, and that topic will be active in the future. So the chances for annoying a member are quite small, and the current solution - relying only on group-level subscription data, rather than topic-level data, is sufficient.

Feedback?

Crap, I forgot to mention another complication.

In theory, calling up a list of gfsub_x values should result in a list in one-to-one correspondence with current group membership. In other words, every member of a group x should have a gfsub_x value. But when I ran the first part of my script, I found that this was not the case. Nearly 100 groups have a slight discrepancy, where (for instance) 17 gfsub_x values were found in a 19 member group.

This might be caused in some case by the double-member bug. But in some cases it's not. That suggests that the gfsub_x data is somehow messed up, and not representative of all group members.

It's easy enough to check group members who don't have gfsub_x. But what to do with them once I've found them? Should they be subscribed?

Yikes. I did some more investigation and I figured out the problem.

On a lark I tried querying to see the public/private/hidden status of all the groups with discrepancies. Every single one was hidden. That suggests (could this really be true?) that email notifications have never worked for hidden groups. I guess I don't know because I'm not in any active hidden groups.

I guess the bright side is that hidden groups will, as of 1.1, have access to email notifications!

wow, if the thing about hidden groups is true I guess it highlights the need for formalized testing of features.

I think that your basic idea of "when in doubt subscribe" is a good policy. Especially if there are only a small number of people who will be subscribed and didn't want to be. It's better than not knowing you're missing something.

We should to something to let users know that we've made modifications to the email notification system and they should check it out and make sure it's set up how they want it. This is really a larger question of how we notify people when we make interface and functionality changes to the site.

The basic strategies seemed to be email and some kind of on-screen or popup notification when the log in to the commons. I think both can be used depending on the situation. In this case the on-screen notification seems to fit.