Bug #324
closedInvite Anyone says can only invite *.cuny.edu but doesn't enforce
0%
Description
See #322 for report.
I think the problem stems from the workaround described in #240. It means that email invitations to non-CUNY addresses will go through, but that they won't be able to sign up for accounts.
I guess I'll have to work out a way to filter for wildcards in IA.
In the meantime, Matt, we have to deal with the invitations you've already sent. Might I suggest temporarily adding the additional domain names to the email whitelist, to be removed when the members in question join, or when this ticket is resolved?
Updated by Matt Gold over 13 years ago
If people click on an invitation sent to a non-CUNY invite, they won't be able to use a non-CUNY address when signing up. But let's say that an invite is sent to someone at xyz@aol.com. They get to the sign-up page and they're told that they have to use a cuny email address, so when they sign up, they use xyz@csi.cuny.edu. Will they still be invited into a group if that was part of the Invite Anyone invitation? In other words, is the Invite Anyone functionality tied to a particular email address or to some variable that is part of the invitation that is sent out?
Updated by Matt Gold over 13 years ago
Since there are only a handful of non-cuny invites in this case, we could add them manually and then invite them to the group through the group interface. that would allow us to disallow all of these other non-cuny domains.
Updated by Boone Gorges over 13 years ago
To answer your first question: No. The plugin looks up group invites, etc by email address.
I think the solution needs to be multifaceted. I propose:
1) Reconfigure Invite Anyone to understand domain wildcard restrictions. This will prevent the problem in the future.
2) Reconfigure our *.cuny.edu core WordPress hack so that it also checks against the Invite Anyone database. In other words, non-cuny addresses will only be accepted if they match an entry in wp_bp_invite_anyone. I can even date this, so that only non-cuny addresses that were invited before today (or whenever the fix for (1) goes live) will be accepted.
The advantage of this approach over the one you suggest is that it doesn't require any manual rejiggering, or the resending of invitations. The disadvantage is that it's a file-system-level change, which means that it needs to be deployed as a release number. We have two options:
a) Release it by itself as 1.0.2
b) Release it with all the other changes on the 1.0-branch as 1.0.2
I am cool with (b) if you are.
Updated by Boone Gorges over 13 years ago
- Status changed from Assigned to Resolved