** Using WeBWorK **

From the point of view of using WeBWorK, would it be a good idea to require that student ID's be unique? It would still not be a primary key, but it would not be hard to insure that no two entries in a course database have the same studentID.

Disadvantage 1: You would have to give practice users, teachers, TAs, observers and anyone else who is not really a student in the course a fake "studentID". You'd need to make sure that this didn't bump out some student's legitimate ID. This is what was done in WeBWorK 1.9. While it was occasionally annoying, it was never more than that.

Disadvantage 2: If you enter a student with a bad login name (and catch it soon enough) you can simply enter the student with the correct login name and then erase the old entry. The fact that temporarily two entries have the same studentID is not currently a problem. If studentID's are unique, then you would first have to give the original entry a bogus ID before entering the new correct entry. --This disadvantage could be overcome with adding a function that changes a students login name. (Since the login name is a primary key, this effectively means copying the old record to a new record with the new key and then deleting the original record. If we are guaranteed to be dealing with an SQL database, then we can assume that the database knows how to do this internally. The GDBM database system did not.)

Advantage 1: In the case of real students it is nearly always a mistake to have the same studentID, so requiring unique studentID's helps to discover errors. -- Can anyone think of a case where they would like to have a single student have to WeBWorK accounts in a single course? If so unique ID's would require that one of the student's accounts have a bogus ID.

Can anyone think of other advantages or disadvantages to requiring unique student ID's in WeBWorK?

Your thoughts?

-- Mike

<| Post or View Comments |>

Here is my take on the student id field. I would leave it the way it is in terms of allowing it to repeat values and be empty. In fact, I would go farther and change its name to "Comment 2", and move it far to the right in the classlist editor (do people enter id numbers and then read them?). After all, the current behavior is that it is treated like a comment.

If people want to keep student id's in webwork, then there should be a slot for it (whether it is called student id or comment 2). But for others, it would be a nuisance to have to enter them. Admittedly, making people put something in the student id field is only a small annoyance for them. But the annoyance is multiplied by the number of students they enter by hand.

John

<| Post or View Comments |>

In that there are obviously people for whom the student ID field is redundant, I'd say requiring it to be unique is probably not a good idea. However, at the moment we actually do use it here, so if only to avoid confusion I like the idea of calling it what it the "student ID".

Gavin

<| Post or View Comments |>

http://webhost.math.rochester.edu/webworkdocs/discuss/msgReader$4018?y=2006&m=2&d=15

http://webhost.math.rochester.edu/webworkdocs/discuss/msgReader$4019?y=2006&m=2&d=15

and

http://webhost.math.rochester.edu/webworkdocs/discuss/msgReader$4021?y=2006&m=2&d=15

<| Post or View Comments |>

Since some people like unique studentID's and some don't, I think it would be useful to have a configuration flag "force_unique_student_IDs".

There are situations where forcing the studentID to be unique is useful. For example recently at Rochester a professor added a student to a course without realizing the student was already in the course (I think the student was switching sections). The professor used a userID that was different form the original (maybe taken from a gmail account rather than from the university assigned email account) and the student ended up with two active accounts. This isn't that hard to remedy once it is discovered but the error would have been caught imediately if studentID's were forced to be unique.

In general, if people use the studentID field for real student ID's I think they should at least have the option of enforcing uniqueness.

Arnie

<| Post or View Comments |>

As for uniqueness, a good middle ground would be to confirm the addition of a user with a duplicate student ID. Maybe we'd want to double-check adding a user with a duplicate first and last name, or a duplicate email address.

We should definitely decouple student ID from password, or at least make that behavior optional when importing a classlist or adding a student. (Other options for setting the password: invalid password, generate a random password and email it to the user, specify a password manually.)

Another idea is to define a number of "custom" fields that could be labeled globally or on a per-course basis. One of these could be used for the student ID if need be.
-sam

<| Post or View Comments |>