Feature requests for adding new users

[dlglin]

When adding new users from the Classlist Editor, WW is hard coded to set the student ID as the initial password. I'd like to see an option to manually set a password, and also to not set a password at all for cases when a course wants to force external authentication for that user.

I'd also like to be able to choose a permission level when adding a new user. Right now I have to add the user, then go back and edit them to promote them to a higher permission level.

[taniwallach]

I like these ideas too.
I suspect that we will need to add additional elements to determine which type of password handling should be used in the form being opened (whether to provide a field to set the password or not) and whether to include a pulldown to set each new users permission level.
About not setting a password - how about a column of checkbox which when marked trigger "not" setting a password for the user. In that case, I think the password should be set to the empty string, which cannot be used to log in.

[dlglin]

This probably warrants some discussion on the best way to handle the interface for setting passwords. Off the top of my head I see several options that people may want:

1. Use an existing field value as the initial password, such as the student ID. This is the current behaviour, and I have never liked it. Having a predictable scheme for generating passwords strikes me as a bad idea, so I would be okay if this option wasn't available. It's worth noting that the Add Course interface in the Admin course requires you to type a password.
2. Manually type a new password for the user. This could easily replace option 1, as it would only require users to copy and paste whatever field they want to set as the password if they want to set default passwords that way.
3. Not set a password at all. I don't like the idea of setting the password to the empty string in this case. It seems to me that not having a password record at all for the user has less potential for vulnerabilities than comparing to an empty string. I don't know how perl encrypts the empty string, but I'm worried that it could lead to problems.
4. Have some sort of method that forces the new user to set their own password. The common scenarios I've seen in other systems are:
   1. Generate a password that expires after the first use, and needs to be changed.
   2. Email the user a one-time login link that allows them to set an initial password.

I realize that option 4 is a bigger project, so I consider that beyond the scope of this discussion.

If we only allow options 2 and 3 (type a password or don't set a password), then I don't know that we need any additional elements for generating the form. One possible interface is to include a password blank with a checkbox beside it labelled "do not set a password for this user", probably with a tooltip that explains that if no password is set then the user will only be able to log in using external methods (e.g. LDAP, LTI, etc.). If the box is checked then the password field could be greyed out.

For the permission pulldown, I think it's easier to just always include it, but make its default value configurable. I would set the initial default to student, but allow individual installations to change it. For example institutions that add students via LTI or csv may only use this form to add instructors, so they would want the default to be professor. Another possible feature here is to add a dropdown at the top that changes the value for all rows in the table.

[drgrice1]

@dlglin: Your point 3 in your last comment is not valid. It is better (and easier to implement) to have a password set to the empty string. That is in fact what currently happens if you don't provide a student id when you create a user, and works fine. The cryptPassword method does create a valid password hash from the empty string, and that is what is saved in the password column. However, that is completely unusable when signing in because webwork doesn't even check for a password being valid if it is given as the empty string.

[drgrice1]

It seems I am wrong about it being easier to implement (perhaps) by using the empty string. The LTI authentication modules create users without a password record at all, and the Authen module does check to see that the record exists. So not creating a record at all would also not be hard to implement and would work the same.

[drgrice1]

The question just becomes, do we care about the behavior of defaulting to using the student id that is currently employed?

If not, then this is easy. You just add a "password" field to both the create and edit user pages, and eliminate the "Password" tab on the main user list (Accounts Manager) page.

On the create user page you only set the password if one is provided, and otherwise no password is created.

On the edit page a dummy string (probably "********") is shown for existing passwords and otherwise the input is empty (meaning the user does not have a current password). If the dummy string is submitted, the current password is unchanged. If the empty string (or a string containing only spaces) is submitted and the user has a password, then it is deleted. If anything else is submitted, then that is used for the password (of course with some character validation both client side and server side).

This becomes more difficult though if you want to preserve the current behavior of using the student id by default.

[Alex-Jordan]

I occasionally have a situation where an instructor misunderstands the relationship between student ID and password. They will think that they can change a user's student ID, and that will then also change the student's password. These interactions are usually pretty frustrating because as you might imagine, an instructor who thinks that is how it works is also less likely to understand me when I explain how things actually work.

So FWIW, I am in favor of making the student-ID-as-default-password become a thing of the past.