Opened 15 years ago
Closed 13 years ago
#2005 closed defect (bug) (fixed)
Be consistent about who can invite whom to different types of groups
Reported by: | bi0xid | Owned by: | boonebgorges |
---|---|---|---|
Milestone: | 1.5 | Priority: | major |
Severity: | Version: | ||
Component: | Groups | Keywords: | has-patch dev-feedback |
Cc: |
Description
Hello there.
When I have been invited to a group, I receive a message which says:
One of your friends %s has invited you to the group: "%s".
But when I visit the link, I have not been invited to the group. I have only been suggested, and if it's private, I must request membership.
Easy option: change the text (diff attached) to:
One of your friends, %s, has suggested you to join the group: "%s"
Changed the format too. One of your friends rocio has invited... is confusing.
It changes too:
- To view your group invites visit: %s + To view your suggested groups visit: %s
Hard option: Code a new function for those who have been invited, so you have a:
You have been invited to this group. Do you want to join it?
Don't know if it's planned, but in the meantime we can use this change.
Attachments (4)
Change History (16)
#1
@
14 years ago
- Component set to Core
- Summary changed from e-mail notification for group invites to [patch] e-mail notification for group invites
#3
@
13 years ago
Bump.
Any thoughts about this? Do we:
(a) Prevent non-admin-mods from seeing/visiting the Send Invites tab of a private/hidden group?
(b) Allow any member to send invites to any group?
(c) Provide a toggle?
Right now we have an ugly mix of (a) and (b) (the ajax checks to see whether you're an admin, while groups_invite_user() itself does not). This is not viable.
I guess I vote (c). It is the biggest pain in terms of number of lines of code required. But I have a feeling that different people are going to expect different behavior here, and if we decide one way or the other without providing an easy way to change, we are going to get some annoying questions.
If everyone concurs, I'll take it on myself to write this one. If you have a different feeling about it, speaketh now or forever hold thine peace.
#4
@
13 years ago
Another issue is the Send Invites tab shows up for all users when they join the group.
The problem here is that users try to use it but it just appears to do nothing, however in ajax.php it's returning false on line 297 in BP 1.2.8:
if ( !groups_is_user_admin( $bp->loggedin_user->id, $_POST['group_id'] ) ) return false;
So it needs to be decided if you want to at some point allow all members to invite to the group, or if you just want admins to be able to do it, the Send Invites tab should not appear. In any event, it should display an error message rather than silently returning false saying something like "Only group admins can send invites"
#5
@
13 years ago
Right. This is a related issue: either show the Send Invites screen and let people send invites in AJAX, or don't show the screen. We might just choose a different default for public vs non-public groups.
#6
@
13 years ago
- Summary changed from [patch] e-mail notification for group invites to Be consistent about who can invite whom to different types of groups
#7
@
13 years ago
- Component changed from Core to Groups
- Keywords has-patch dev-feedback added; group notification admin removed
- Priority changed from minor to major
- Type changed from enhancement to defect
Gah. I thought that this would be really easy to fix, but I ended up having to tear apart the entire groups component to get this extra toggle. I'm going to chalk this up as a good learning experience (now I know what needs to be rewritten!!)
2005.001.diff is a pass at adding the necessary toggle. It works as advertised. The question on the table is whether the other devs think it's a reasonable addition to BP core. (Keeping in mind that *something* has to be done about the inconsistencies in this ticket, and the solution I've outlined in this patch is probably the most flexible from the user's point of view.)
Feedback welcome.
#8
@
13 years ago
As per Paul's prodding in IRC, I'm going to have another look at this. The more I think about it, the more I think that we can probably get away with using groupmeta for the purpose instead of the more intensive schema change. This is because the setting in question is not needed on group-list loops, but only when looking at a single group page.
I'll work up another patch to reflect this.
I would really rather not punt because I consider the problem with this ticket to be a rather severe bug in the way BP works at the moment.
#10
@
13 years ago
As promised, 2005.002.diff is a new version of the patch, which puts invite_status in groupmeta rather than in the main schema.
I assume that the OP's issue is that it's possible for A to send an invitation to another member B to join a private group, even though A is not an admin or a mod of that group, so that B is unable to accept the invitation.
If so, that seems like a bug. Either non-admin-mods should not be able to send invites to private groups, or they should be fully function invitations.
Regardless, I'm not able to reproduce it on the latest trunk. I am unable to send an invitation to a private group as a non-admin. I can get to the Send Invites page, and I can see a list of my friends in the left-hand checkbox list, but when I check one of them, the AJAX that creates the invite and puts the friend on the list on the right-hand side of the page fails, so the real invitation never gets sent. This also seems like a bug.
So there is a larger question about how BP should handle invitations to private/hidden groups. My feeling is that one of two things should happen:
1) There should be a switch in the group admin area that allows admins to choose whether non-admin-mods can invite others to the group. If set to No, then non-admin-mods will not see Send Invites at all.
2) We allow all members of private groups to send invitations. If people want to control who can and can't send group invites, they can use a plugin like http://wordpress.org/extend/plugins/invite-anyone/
I think that (1) is a reasonable solution, though it takes a bit more work. I'd be interested to hear feedback on that idea.