CUNY Academic Commons

Thanks for reporting, Michael!

Hi Michael -- were these new notifications related to new mentions/activity events?

I've spent a bunch of time trying to trace this down, and I think I've got it mostly put together. Michael, feel free to skip to the tl;dr - I'm writing this all out for posterity.

==
A number of groups on the Commons are using the External Blogs tool to specify RSS feeds that should be pulled into their blogs' activity feeds. Usually this works fine. But in a few cases, the group admins have entered the URL of a Commons RSS feed that is not publicly viewable, such as that associated with a private group; when you pull up the feed URL in a browser (as a logged-out user), you get a login page asking you to log in to view the content. The URLs look like this: http://commons.gc.cuny.edu/groups/questionpointatcuny/feed/. The external blogs plugin uses WP's RSS-fetching library, which essentially sends a cURL request to the URL in question - the virtual equivalent of an un-logged-in user. However, instead of redirecting to the login page (like a normal browser agent would be), WP recognizes that this is an RSS agent, and tries to be clever by finding a similar feed URL that is available. In this case, it settles on http://commons.gc.cuny.edu/activity/feed/ - the sitewide feed.

Now, it just so happens that during one of these fetches, some comments from the ITP Core 2 public blog had been posted to the sitewide activity stream; furthermore, it so happens that all of them had a mention of @mandiberg. When the items were reposted to the offending group, notifications were (correctly) sent to Michael to notify him of new mentions. In other words, the URLs that Michael got in the emails all correspond to actual, separate activity mentions that happened in blog comments on the ITP Core 2 blog - I've cross-referenced all the activity IDs from the URLs that Michael has shared above.

The problem with the incorrect redirects lies in BP's activity permalink router. The activity items are stored as type 'exb' ("external blog"). They are associated with the 'groups' component, and in particular with the offending group described above. They are not associated with any individual user (because the external blogs plugin assumes that the feeds come from non-members). BP doesn't natively know how to route activity items that don't have user_ids associated with them, but we have some custom functionality on CAC that routes these items to their "primary_link" attribute. And it appears that there is a bug in the external blogs plugin that incorrectly sets the 'primary_link' of the activity items corresponding the fetched items to the RSS primary link of the final item in the list. In this case, it happened to be a group-join by Jorge Matos. Thus the redirect.

tl;dr
So, in sum, in addition to a sorta bizarre combination of normal behaviors on the site, a couple bugs are conspiring to cause the observed behavior:
1. Some group admins have inadventently entered external blog feeds that are not actually accessible to our RSS fetching mechanisms
2. There's a bug in the external blogs plugin that causes primary_link values to be set incorrectly

I'll make some interim fixes for each issue.

Actually, on examination, I'm not going to try to patch the routing issue. BP's router was really acting properly in this case, given the faulty information that it had. If the primary_link value had been correct, you'd've been redirected to the activity item within the context of the offending group; while annoying (your post never should have been aggregated there in the first place), this would have been the correct behavior. The previous two fixes should prevent further instances of this kind of problem.

I'm going to mark the issue as resolved, given the above discussion. Michael, the activity links you've shared above will continue to be inaccessible (they'll route incorrectly) but you should not get any more items like this in the future. If you do, please post an update here. Thanks.