Bug #21093
closedError Joining Public Groups
0%
Description
Twice now I've run into an error trying to join a public group on the commons. Are others out there experiencing this issue? I've attached an example of the error message with this ticket.
Files
Updated by Colin McDonald about 2 months ago
I was just able to reproduce the error in Zach's screenshot trying to join this group:
Updated by Boone Gorges about 2 months ago
- Status changed from New to Testing Required
- Target version set to 2.4.8
Thanks for the report.
The invitation is failing because of a check for 'invite_status':
https://github.com/cuny-academic-commons/cac/blob/31cc2e8565d5115915891fbe3b82f3ab063f58c4/wp-content/plugins/buddypress/bp-groups/bp-groups-functions.php#L672
A number of groups on the Commons don't have this value set:
mysql> select count(*) from wp_bp_groups where id not in (select group_id from wp_bp_groups_groupmeta where meta_key = 'invite_status'); +----------+ | count(*) | +----------+ | 413 | +----------+ 1 row in set (0.01 sec)
I see a few things that can be addressed.
First, we can provide a fallback value for the 'invite_status' check. This is something I have done right away, and deployed to the production site. Zach and Colin, perhaps you could test. https://github.com/cuny-academic-commons/cac/commit/31cc2e8565d5115915891fbe3b82f3ab063f58c4
The commit linked above is a workaround for what I think is incorrect behavior in BuddyPress. It was introduced in https://buddypress.trac.wordpress.org/changeset/13874 as a way to work around groups' being joined before the creation process was complete. Prior to this change in BP, groups without 'invite_status' would essentially behave as 'invite_status=members'. In fact, BP has a wrapper function that explicitly provides this fallback: https://github.com/cuny-academic-commons/cac/blob/31cc2e8565d5115915891fbe3b82f3ab063f58c4/wp-content/plugins/buddypress/bp-groups/bp-groups-template.php#L2421 My first thought was that groups_join_group() should use this wrapper function instead. However, this would probably reintroduce the behavior that changset 13874 was meant to prevent. So I think that, instead, BP ought to move this check out of the business function groups_join_group() and somewhere a bit higher in the stack - probably groups_action_join_group() and friends. If that change were made, then my workaround would no longer be necessary. Ray, if this reasoning seems right to you, I can work up a ticket for BP.
Separately, there's a question as to why some groups don't have invite_status set. I thought maybe it was a problem only for legacy groups, but a look at the problematic groups suggests that it's spread kinda randomly over old and new groups: select id, name from wp_bp_groups where id not in (select group_id from wp_bp_groups_groupmeta where meta_key = 'invite_status'); I'm not sure how important it is that we figure this out, especially if the fallback behavior is appropriate in all cases, but I thought it was worth mentioning in case Ray had any bright ideas.
Updated by Raymond Hoh about 2 months ago
So I think that, instead, BP ought to move this check out of the business function groups_join_group() and somewhere a bit higher in the stack - probably groups_action_join_group() and friends. If that change were made, then my workaround would no longer be necessary.
I think this approach helps a tiny bit, but it would still be technically possible for a user to join a private group in the window where the group admin is still configuring the group's privacy settings to private or hidden, but this would be better than nothing.
I think it would be ideal in BuddyPress if a group's status was set to 'private' or 'hidden' by default instead of 'public', then this issue would not occur.
Separately, there's a question as to why some groups don't have invite_status set.
I believe this occurs when a user only goes through the first step of the group creation process and navigates to another page afterwards.
I've been checking a few of the recently created groups that do not have their invite_status set and a bunch of other group meta entries are missing that would normally be set such as ass-default-subscription or forum_id on the second step of the create process.
Updated by Boone Gorges about 2 months ago
I think this approach helps a tiny bit, but it would still be technically possible for a user to join a private group in the window where the group admin is still configuring the group's privacy settings to private or hidden, but this would be better than nothing.
I don't know about that. What I'm proposing is that BP continue to check 'invite_status', but not do it in the business function. You'd do it basically everywhere in BP where users can join public groups:
- https://github.com/buddypress/buddypress/blob/fdba478b1efcaff67a9e23442d1e1a4293a13cef/src/bp-groups/actions/join.php#L15
- https://github.com/buddypress/buddypress/blob/fdba478b1efcaff67a9e23442d1e1a4293a13cef/src/bp-templates/bp-legacy/buddypress-functions.php#L1619
- https://github.com/buddypress/buddypress/blob/master/src/bp-templates/bp-nouveau/includes/groups/ajax.php#L176
So the effect would be pretty much the same - users would be unable to join a group through any of the native interfaces if invite_status was not set - but you'd be able to use groups_join_group() in a custom script.
I think it would be ideal in BuddyPress if a group's status was set to 'private' or 'hidden' by default instead of 'public', then this issue would not occur.
Yes, this seems like a good idea, though it would probably have its own set of backward-compatibility concerns, particularly when groups are created programatically. It also wouldn't help with existing groups that have already been created without an invite_status. Fixing the regression seems like a good first step.
I believe this occurs when a user only goes through the first step of the group creation process and navigates to another page afterwards.
Good call, this is probably the case. Interesting that some of these "abandoned creation" groups are actively used.
Updated by Raymond Hoh about 2 months ago
So the effect would be pretty much the same - users would be unable to join a group through any of the native interfaces if invite_status was not set - but you'd be able to use groups_join_group() in a custom script.
Ahh, gotcha! I misread what you were talking about initially. I think this makes sense. Feel free to work up the fix upstream to BP.
Updated by Boone Gorges about 2 months ago
Thanks, Ray! I've opened a ticket https://buddypress.trac.wordpress.org/ticket/9241 It's kinda complicated and I don't have a ton of confidence that it will be easy to fix in a clean way, but we'll see what the team says.
Updated by Colin McDonald about 2 months ago
Thanks, Boone and Ray. I was just able to join the New Media Lab that I wasn't able to join on Friday. Zach, do you want to see if you can do the same?
Updated by Boone Gorges about 2 months ago
- Status changed from Testing Required to Resolved
Thanks all for the feedback.
It looks like BP will probably roll in at least the more conservative of my suggested fixes, so I think we can close this ticket.