CUNY Academic Commons

Matt,

Could you tell me a little more about what computer you were on when you experienced the original error? I'm wondering if this could be related to our ongoing login issues related to cookies. #228, #2193.

If it is, we might want to start another meta ticket to consolidate login discussions the way we did with CAC Featured Content while I was rewriting it.

I think we get the "Page Not Found" page because that group is a hidden group.

We've always thrown a "Page Not Found" for hidden groups in BP:
https://buddypress.trac.wordpress.org/browser/tags/1.6.1/bp-groups/bp-groups-loader.php#L254

This doesn't help when we're using the Group Email subscription plugin.

What's a good plan of attack, Boone? Perhaps check to see if a hidden group URL has an action, if so, use bp_core_no_access() instead of throwing a 404?

Boone, I was thinking about this issue yesterday when I was looking into GES.

We could probably address this directly in GES since we already pull up the group object during email sendouts. We could check if the group is hidden, if so, switch the link to use wp-login.php?redirect_to=LINK_TO_HIDDEN_GROUP_FORUM_TOPIC.

I think this solves the problems mentioned here. What do you think?

Ray - That sounds good. When a logged-in user attempts to access that URL, he'll be redirected right along to the group forum topic without having to log in, right?

When a logged-in user attempts to access that URL, he'll be redirected right along to the group forum topic without having to log in, right?

Just tested this briefly and it doesn't redirect for logged-in users. I thought it would! :(

I think I'll do a combination of what I suggested and what you suggested here.

Boone, I've added a pull request to the GES repo for this issue.

Let me know what you think.

This means that Docs emails need the same treatment as forum post emails. I'm not sure how smoothly this is going to work, because Docs emails are generated by the generic activity handling function, and I'm not sure at a glance whether we should extend the treatment to all group activity items. Ray, if you could chime in with your thoughts, that'd be great.

In an ideal world, BuddyPress would handle private group access for all subpages and redirect the user to login if necessary. Hidden group pages are another matter altogether as discussed here.

As for BP Docs, do we want to do what we did with GES? Or should I write some custom code for CAC?

For new docs, I could probably filter "bp_docs_activity_args" to do what we need and piggyback off of the redirection code in GES to address this.

Likewise for comments on docs, I can filter "bp_docs_comment_activity_args".

In an ideal world, BuddyPress would handle private group access for all subpages and redirect the user to login if necessary. Hidden group pages are another matter altogether as discussed here.

Yes, it'd be nice for BP to be smarter about this, though as you note, it wouldn't be a truly general solution for our purposes, since the group notification issue applies to hidden groups as well as private groups. So I think this is a problem that has to be solved even aside from BP core.

I could probably filter "bp_docs_activity_args" to do what we need

You mean, to change the primary_link? I was thinking that this issue could be addressed in GES, by applying the wp-login.php trick in the general activity logger function https://github.com/boonebgorges/buddypress-group-email-subscription/blob/master/bp-activity-subscription-functions.php#L353 (so, basically a port of https://github.com/boonebgorges/buddypress-group-email-subscription/commit/c382771 to ass_group_notification_activity()). Then we don't have to build anything Doc specific, and we'll automatically fix activity like bp-group-documents at the same time. What do you think?

okay -- thanks.