Feature #1261
closedAllow non-CUNY registration with passcode and admin verification.
0%
Description
See also #370, though this ticket will not provide special "guest" accounts - accounts created in this ticket will be full-fledged Commons accounts.
As discussed in our last Commons subcommittee meeting, I'm going to implement a feature that allows certain non-CUNY email addresses to register for a Commons account, given certain prerequisites. Here's my suggested setup:
- When someone enters a non-CUNY email address into http://commons.gc.cuny.edu/register, use JavaScript to display a required field directly below the email field that says something like: "You can register without a cuny.edu email address only if you've been given a signup code", along with a field for a passcode.
- When the registration page is submitted, non-CUNY email addresses will continue to be rejected, unless a valid code is provided.
- Codes can be created by admins on a new Dashboard panel that I'll create.
- Codes can also be associated by the admin with a Commons group. When a non-CUNY user joins with a given code, he will automatically be placed in that group
- Users who register using a valid signup code will not automatically be given accounts. When they submit their registration (given that they've provided a valid code), their account will be marked as "unverified" (akin to a user who has not yet entered a validation key), and an email will be sent to the admin informing him that a registration is awaiting manual verification. Verification will take place either on the Unconfirmed panel (already exists) or on the panel corresponding to the signup code, whichever ends up being easier to implement. When a registration is confirmed, the user will receive an email notifying them of their verified account status.
Amendments and revisions to this picture are welcome, before I get started on it. Marking as high priority, as Matt suggested that it needs to be done soon.
Related issues
Updated by Chris Stein over 12 years ago
Was just about to add this, glad I checked first.
I think the process you outlined is a good start. Because there are a few steps I'm going to write it again to make sure I understand. I'm also going to add a few steps in a kind of a larger scenario. This starts after the functionality that prevents non-cuny from registering without a code:
1. Someone decides they want a group with non-cuny people in it
2. That person contacts the Commons
3. We decide (process?) that in this case it's OK
4. A code is generated for that group
5. The code is given to the group admin with instructions (should be written down) on giving it out to non-cuny types
or
5b. A Commons admin asks for the emails and then sends them out without telling the group admin about the codes
6. The person gets an email with the code and instructions (the instructions part is why we might want to send out the email)
7. The person goes to the Commons register form and registers using the code
8. User is registered as "unverified"
- does a custom email go out explaining current status to user, and that they will be verified by Commons admin?
9. Commons admin goes into Dashboard and verifies the user, They are now part of the group and identifiable as non-cuny
10. User is sent an email and can log in to the commons
- is this also a custom email akin to the 10 things but modified for non-cuny?
This process seems to solve the problems each group of people is having
A. Groups want non-cuny people
B. Commons admins want better control of non-cuny people
C. non-cuny need clear information about the process and how to use the commons
If this process is confirmed in addition to the functional areas Boone is already assigned the following would have to be written:
1. (possibly) information on the process for group admins, or whoever is interested in bringing non-cuny people to the Commons
2. Instructions for registering with the code
3. Email to non-cuny after filling out registration form
4. Email to non-cuny after registration is verified.
This process seems good but also a bit complex. That may just be how is has to be. If anyone has ways to serve all three groups (group admin, commons admin, non-cuny) and make it simpler that would be great.
Boone, a couple of functional questions it raised (you mentioned most already, just laying out to see if I see anything else):
- javascript when selecting non-cuny to ask for code
- also verification that when form is submitted emails that aren't .cuny.edu have both non-cuny selected and a code entered. This code also must be validated
- are they automatically signed up for the group associated with the code? If so when. From code perspective probably easier on register form. From UX perspective it's probably better after they're verified (step 9) so they only see members who can log in.
- custom email sent when registering
- custom email sent when commons admin verifies
I think we're agreed, but wanted to check, that this ticket does not address a different issue of limiting what non-cuny or undergrads can do on the site after they have registered. This just has to do with registration. Right?
Finally, are we going to try to apply this to undergrads? That's more difficult because they shouldn't select non-cuny and they can just register anyway so the process is not enforceable. I'm thinking that is separate.
Updated by Boone Gorges over 12 years ago
Thanks for the additional details, Chris. My impression is that your additional steps (requesting a non-CUNY code) will come about through external channels, like email. Building a technical infrastructure for these requests doesn't seem like a great use of resources.
does a custom email go out explaining current status to user, and that they will be verified by Commons admin?
Yes, and we probably also need to have a custom error message for when these users attempt to log in.
This process seems good but also a bit complex.
The more we talk about it, the more complex it becomes. I'm still fine with doing it for 1.3, but it would be nice to get verification from Matt that this issue is sufficiently important to load a bunch of development time into it in the immediate future. Personally I am indifferent.
this ticket does not address a different issue of limiting what non-cuny or undergrads can do on the site after they have registered. This just has to do with registration.
Right. That's what I meant by "See also #370, though this ticket will not provide special "guest" accounts - accounts created in this ticket will be full-fledged Commons accounts."
Finally, are we going to try to apply this to undergrads? That's more difficult because they shouldn't select non-cuny and they can just register anyway so the process is not enforceable. I'm thinking that is separate.
I think you're right.
Updated by Matt Gold over 12 years ago
I do think it's important enough to merit the development time involved, but I'd also be interested in finding ways to make the process less complex on a technical end and on the user end.
Is there any way to add a marker of some kind in the user table so that if and when we activate a piece of functionality associated with ticket 370, we can apply it to accounts created through this process?
The point in the process that concerns me the most is having admins verify the accounts before they are created. That could be a pain when 40-50 new accounts are involved. But I suppose that we won't often have that many people signing up at once, so it should be okay.
Updated by Boone Gorges over 12 years ago
I'd also be interested in finding ways to make the process less complex on a technical end and on the user end
I'm open to suggestions. Removing the verification requirement means that anyone who has the code can sign up (and will be auto-joined to what may be a private or hidden group with sensitive material). The likelihood for mischief is perhaps small, but it would be pretty bad if it were exploited.
Is there any way to add a marker of some kind in the user table so that if and when we activate a piece of functionality associated with ticket 370, we can apply it to accounts created through this process?
Yes, will do.
The point in the process that concerns me the most is having admins verify the accounts before they are created.
See my comment above. I'll build an interface that makes it possible to verify many users at a time, though this adds a bit of work for me.
I've carved out some time on Thursday to start this work. I have a feeling that it'll take most of the day, with all the moving pieces involved. I'll report back after I finish a first pass at it, and maybe we can discuss at Friday's meeting if you think it's warranted.
Updated by Boone Gorges over 12 years ago
I have a first pass at this in the master branch. Maybe we can look at it tomorrow as a group, as there is currently no way for you to test unless you have a local clone of the site.
Updated by Boone Gorges over 12 years ago
- Status changed from Assigned to Reporter Feedback
OK, first pass is up on cdev. Here's the workflow for testing.
AS AN ADMIN:
- Log into the Dashboard of the main blog.
- Under Non-CUNY Signup Codes on the left-hand menu, select Add New Signup Code
- Enter a description (for your own use) and code (this is what the registrant will use).
- The Add To Groups box does some AJAX autocomplete, and allows you to specify groups that the user will be auto-added to when signing up using this code. Add a group or two for testing.
- When you're done, save the Code with the Publish button.
AS A NON-LOGGED-IN USER:
- Go to http://cdev.gc.cuny.edu/register/
- Enter some info. When you enter a non-CUNY email, a passcode box will appear (since I was doing some javascript crap here anyway, I also added a bit of email address validation - so you'll get a warning if you type an email address that is not properly formatted, for example).
- Enter a signup code. When you leave the field, it'll check to make sure it's a valid code - play around with incorrect ones.
- Complete your signup, and click the activation link in the email. Log in and make sure you've been added to the group in question.
There are a few pieces of this puzzle that have not yet been implemented:
1) There is no admin interface for tracking signups using a given code. I am keeping track of who signs up using a given code, but there's no place in the admin where I'm displaying that information. I'm thinking that maybe I'll put a list on the individual code page in the dashboard - a meta box that shows the users who have registered using that code. Other ideas welcome.
2) I've left out the admin verification. Matt, you made it sound like this would be an onerous requirement. I can add it in if necessary, though it'll take quite a bit of work, as it'll require me to create a custom "in limbo" status for the Commons.
Updated by Boone Gorges over 12 years ago
- Status changed from Reporter Feedback to Resolved
Hi Matt. Just an update on this. I'm going to go ahead and leave it in the release, since it's totally inert unless you, as the admin, actually set it up. The only visible piece of it will be on the signup form, where if someone fills in a non-CUNY address, they will see an additional field asking them to fill in a verification code (but there will be none, so it will never complete). We can iterate on the functionality as you start to use it.
I'm going to mark this ticket resolved for the time being, to clear out the 1.3 milestone. When you find a chance to start using the functionality, and have requests or bugfixes to report, you can either reopen the ticket (moving it to a future milestone) or open separate tickets. Thanks.