Template courses

[Alex-Jordan]

I'd like to have the ability to turn a live course into an archive, except with all of the user data removed. I've been thinking of this as a "template course". The use case is that a term has ended and faculty are happy with the live course they developed. They want to use it in future terms. But having all the old user data could be a problem. It's mitigated by the "clean course" tool when you unarchive a course later. But at least with RS hosting, an issue is that some schools don't want RS to retain any student data longer than is needed. They ask me to delete their course, but also would like to clone their old courses later. So it's either a hassle for them to import their content on their end into a blank shell course, or it's a hassle for me to archive their course, reconstitute it cleaned, then archive it again as a "template". And then make sure I delete the original course and the cleaned up course at the right times. And all without having any course name conflicts.

Does anyone have ideas for how this might work? I have gone through a few ideas that try to leverage as much existing code as possible. I run into problems when you consider that the name of the "template" archive file should probably differ from the course ID of the original course.

A problem is that you don't want to remove that user data from the original course. And then there is no good way to remove the user data once a course is archived. You could consider copying the live course before you archive it to a template, but then we have an issue of course ID conflicts.

Another problem is that once you have a course archive file, there's no good way to give a new ID to the course it holds. (There is a hack way to change the name of the root folder in the archive, and replace course ID strings in particular places within the sql dump. But that last bit feels quite fragile.)

[dlglin]

@drgrice1 said he has done some work on a new course archive format that doesn't use a mysqldump. If we went in that direction then I would think it shouldn't be hard to set up an interface where you could choose what was included in the archive. In addition to your use case I could also see wanting to include instructors but not students in the archive.

This made me think about the relationship between course archives and assignment exports. If we don't include users then a course archive contains assignments, course settings and all files associated with the course (am I missing anything?). At that point we're not far from using the same mechanism to export a single assignment (or set of assignments). The challenge there would be that if you are using this to export individual assignments then you wouldn't want the whole templates folder, just any problem files and macros that are used by problems in the assignment(s), which would require some additional logic to determine.

Thinking longer term, we should eventually get to a point where the database table names are not dependent on a human-readable course ID that is set by the administrator. In that case (and possibly even with our current DB structure), it makes sense to not have the course ID even included in the course archive. With the current DB this would mean that the user would have to enter the desired course ID when unarchiving a course (which could default to the filename). In the future, we could have a generic internal identifier for each course, which means that the only thing necessary from the course archive would be the course name, and we already have a mechanism to change that when unarchiving a course.