## Features & Development

### Unarchiving- Removing users

by Mark Hamrick -
Number of replies: 4
I have successfully tested archiving and moving courses from one server to another. My only problem: the archived course has 500 students in it, and I need a convenient way to get rid of all of them. There has to be a better way to get rid of them besides checking each one. Is this a feature I am missing?

### Re: Unarchiving- Removing users

by Michael Gage -
I don't think you are missing anything. This is a convenient feature that should be added. It should be possible to add javaScript code similar to that which exists on the Library browser.

A possible work around, for this many students, would be to (1) export all
of the homework sets so the set definition files are up to date and then
using the original course as a model and (3) import all of the homework sets.

This will be a bit faster than checking the 500 students. You will get all
of the homework sets installed and no students.

### Re: Unarchiving- Removing users

by Jason Aubrey -
I had an issue like this one time, where I had to remove a lot of students from a course. The firefox extension "CheckBoxMate" came in handy:

"Check multiple checkboxes with ease by drawing a box around them to automatically select them all."

Jason

### Re: Unarchiving- Removing users

by Xiong Chiamiov -
Mike failed to mention that he implemented this shortly after you requested it, so you won't have to deal with it again in future versions :).

### Re: Unarchiving- Removing users

by Michael Gage -
That was fast. :-) I just wrote and uploaded the "select all" widgets last night. :-)

Jason, I'm glad to hear about the existence of the Firefox widget -- that may be an easier solution to some similar requests for this feature which is handy, but not used that often.

I uploaded the file with the widgets to the HEAD distribution mainly to make it easy for Mark to obtain them and try them out -- below is a conversation about issues that arose when he worked with large courses (I'm working with smaller class sizes here.) The basic points are:

(1) An instructor could accidentally delete the admin, or make other unexpected deletions using this feature (a case of too much rope :-) )

(2) Deleting 500 students puts a major load in memory and CPU time on the server. This new feature makes it easier to do just that so it would be done more often. What this overload really highlights is the fact that WeBWorK could use a major database fundamentals overhaul (the last one was designed and implemented 8 years ago) particularly for use in large classes.

Hi Mark,

Thanks for testing this and for the feedback. There are some issues which don't arise when you are working with relatively small samples. :-)
So this is a big help.

On Jul 23, 2009, at 5:35 PM, Mark Hamrick wrote:

Mike,

I have it working on my test machine. It works great.

My only concern is should this be an admin only option? I have a couple concerns about allowing anyone to use it.

1) The select all will select all user including admin. Then you delete all the users including admin.

I thought that we already had a separate check that the user running the page could never delete themselves.
But of course I don't actually try to test this anymore except very rarely by mistake. :-) If you can erase yourself then I'll have to go make that
safety feature more fool proof.

An instructor could erase the admin -- but since the admin has access to the server it is pretty easy to reinstall yourself in a course (I can send you my simple script for this if you like-- instructors on our server often delete me from their course or demote me to student to spare me the email and then I have to give myself access if they need help. )

We could also give admin's a permission level of 15 and make it impossible to delete someone with that permission level without demoting them first. That
would increase safety, but would on occasion be a hassle of its own.

2) My test course had 500 users in it. Once the delete all operation was executed, 2GB of memory and 80% of CPUs were consumed. This is not something you would want to occur if the server was under load in production.

This is true. Of course the same load would occur if the admin or instructor checked the 500 users by hand and then hit "take action", but the chances
of that happening by accident are zero, and it's likely that most would do the deletions in batches. Both the memory use and the high cpu use are
more fundamental aspects of the data management that will need a closer look as we manage larger WeBWorK courses. It's not something
that we can fix quickly or easily with a few code modifications.
This may mean however that for now we should not provide the convenience of checking all student entries at once.

These concerns might only be applicable to me, if so please ignore. I am not sure how everyone else sets their servers up.

I don't think I'll make any further changes right away. This ability to mark all entries at once carries some risk. We could restrict it only to admins
but the risk is still there. In addition when I host courses for other schools I ask that the instructors take responsibility for deleting students from their courses and reusing them whenever possible. This is a point in favor of making the "select all" feature available to instructors.
Most of these have class sizes under 60 but even marking 30 check boxes, much less 60 is annoying -- even if you only do it once a semester.

So ... the current stable release will not get the "select all" feature at least for now. The HEAD release will have it for the time being
and we'll use it in the next release unless we end up thinking better of it.

I'll announce this feature by replying to your original request online in the forum
including some of the comments you have made above and we can let the "bleeding edge" aficionados try this out and offer suggestions. You are not
To get this "select all" feature use