Should "Username" be an email address? What additional info do we want to collect when users register?

[MatthewHeun]

• [x] Seems like we will want to contact users. Using an email address will allow us to do so.

• [x] Also, we could verify email addresses when creating accounts.

[rpruim]

I think we should collect and maintain email addresses, but that doesn't mean they need to be the username. In addition to using email to contact users, email can be used for password resets.

I'm guessing Django includes all this sort of stuff (including confirmation of email) as part of its login module.

[rpruim]

Is there any other information we want to collect on users? (Academic affiliation? Country? etc., etc.)

[MatthewHeun]

Institution and Country would be great. Could we ask for a couple sentences on their intended use of the data?

[kenny5033]

Email verification:

• A UUID is generated for a user, which is only accessible in an email sent to the provided address. If the user goes to the correct link and presents that UUID (a link to this is generated for them and placed in the email), their account will be created.

• Currently, these UUID to account associations are just stored in memory, so if the server goes down, the user would need to fill out the sign up form again. Perhaps we should move these to the database to be more persistent? Or could just be written to disk for the same effect.

• Also currently, the emails are not actually sent. We need to authenticate with an SMTP server to truely send the emails. Right now, they're printed to the console. Should we piggyback off Calvin's ursa server? We would need to get authentication credentials.

Institution and Country are now asked for and recorded in the users database in the sign up form. An intended use section could easily be added now. If we did add it, would we want to make it optional? Or move it to a different location where a user could fill out personal information if they wish?

[rpruim]

Some thoughts here:

• [x] We definitely want to avoid people having to "sign up" more than once.
• [x] Email verification as part of sign-up is a good idea if for no other reason than to confirm that the email was entered correctly (and can be used for things like password resets).
• [x] It used to be that Calvin's SMTP server was not very protected. (I wrote a little utility that took advantage of that -- with CIT knowledge.) Not sure if this has changed since then. But we might prefer to be independent of Calvin's SMTP anyway, if we can. This would make it easier to migrate the entire app to a non-Calvin space and makes us less dependent on ongoing CIT support.
• [ ] For institution, I'd suggest we get the type (Academic, Government, Industry, Non-Profit, Other) as well as the name. Perhaps we make the name optional?
• [ ] Free-form answers about intended use could be interesting, but will be harder to batch process. So pros/cons there. One option would be to have several options (have to think about what options make sense) and also ask for an (optional) text description of how they plan to use the data. [Note: If we gather this information at sign-up time, people might not know, or might just be experimenting. It would be interesting to re-ask this question later (triggered by time or amount of usage or some combination), at which point they may have better answers to the question.]

[kenny5033]

STMP comment broken into its own issue @ #34

[kenny5033]

This issue has been open for a while. We should decide on exactly what information we want to collect from users at the signup page.

Currently it is unknown whether we will have users check a box at signup if they are IEA approved, but the other fields should be finalized.

[kenny5033]

Decided on:

No free form answers anywhere on the site (at least not for the next couple years)

Have a required drop down for institution type including

• Academic
• Government
• Industry
• Non-profit
• Other

With an optional box for institution name

[kenny5033]

The above has been added and a full user signup process has been tested and successfully completed. Closing accordingly.