CUNY Academic Commons

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.

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.

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.

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.

That sounds great. Many, many thanks!

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.

Cool. Thanks!

Great -- thanks, Boone.