End of term procedures?

[SethBattis]

I'm wrestling with how Canvas classifies courses as "available" to different audiences. My measure of availability is that the course shows up in the list of courses returned by a call to:

GET https://instance.instructure.com/api/v1/courses/state=available

This particular API matters to me because we use a planner tool in-house to help students develop real plans around their homework assignments that, well… it works better when it can ask for a list of courses that the student is currently in.

What I've determined empirically so far is:

• If the course is unpublished, it's not available to either teachers or students
• If the course is published an in a term that is current or past but has not been "hard concluded" (either by clicking the "Conclude Course" button before the end of term or making a DELETE call to the course endpoint later on), it is available to teachers and students.
• If the course is hard concluded, it is not available to teachers or students.
• If the account-level "Restrict students from accessing courses after end date" is set, it has no impact on availability of courses (at least in sub-accounts). I have not experimented with locking that setting, because… why bother?
• If the course-level "Restrict students from accessing course after end date" is set, it is available to teachers and students receive a truncated version of the course that is just the id and "access_restricted_by_date": true, which is progress of a sort.

I've seen a number of work-arounds mentioned (e.g. moving all courses from past terms to an admin-only sub-account), which kind of defeats the purpose of faculty having access to their old courses both for archival and re-use purposes.

I'm leaning towards just writing a (not very complicated) script to hard-conclude all courses in a term that I can run the day after the term ends, but… I'm doing it with very ill grace.

Do others have perspective?

[melodyc_lam]

@SethBattis Just curious, have you used the "masquerade" ability through the API or is this a tool that's run on a student's account (so you can query the API within custom JS)?

Also, is there a reason why you don't want to restrict students from accessing courses after the end date? I find that setting to be valuable since often content gets re-used and that presents cheating by students. That setting does get respected by course access, no matter if the course gets concluded or not.

I'm at a K-12 and we have subaccount admins available at the school subaccount level -- these admins also get access to the Archive subaccounts that we have to store previous courses. That being said, we also communicate before the end of the year what happens to courses and give a very generous grace period (until June 30) to backup course content through the export function or copying into a sandbox for re-use/editing (we don't archive sandboxes). We also only hard conclude courses at the end of the year, not at the end of the term (as students can't access courses after the end date), since we have a mixture of terms (we have 3 calendars + yearlong and semester termed courses).

I do have a series of scripts that I run in the summer to clean up courses that utilizes the SIS import system (leveraging Canvas to help me conclude and move courses instead of doing an API call) -- let me know if you want to see examples. Hope this helps!

[SethBattis]

@melodyc_lam I 100% _do_ want to restrict students, I just don't want to restrict faculty, and I don't want to have to make per-course settings changes. (And don't want to have to rely on faculty making their own exports.) My observation is that restricting students at the account level (at least for courses in a sub-account) seems to have no discernible impact.

There's definitely a layer (at the moment) of me being annoyed and not wanting to have to do things like update my course templates and write end-of-year scripts because this feels like a dumb issue (I've set the setting at the account level, I've configured the term dates, I see no reason why the course should still be "available" to students) and I am 100% digging in my heels irrationally.

I am of course, capable of doing all these things, once I get out of my current state of pique.

Our courses are organized into major sub-accounts by things like Academics, Activities, and Advisory Groups, with all of the Academics sub-account courses being synced out of the SIS (along with term information) into sub-accounts organized by department. We have faculty set up as "admins" on the academics account with access to browse each other's courses (but not grades), and then deans and department heads set up as admins on appropriate sub-accounts to also be able to browse grades.

I've got the restrict-student-access-by-date setting turned on on our root account, and the course is in a sub-sub-acount of the root, which may be impacting the issue… but which still doesn't make sense to me in my current state of appalled outrage. 😉

[SethBattis]

Oh, and the tool is making the request using credentials issued to the student (although it could easily be tweaked to masquerade as the student -- or to filter by date on its own). Again: fit of pique.

[SethBattis]

FWIW, I did end up just writing a script (details are [here](https://github.com/groton-school/canvas-cli/blob/36b1aa5ea1d40276fdcf7623afc7739d37be0508/packages/c...)). It's just one more thing to add to my end of term checklist!

It means that I can just pop open the command line and run:

> canvas courses conclude --account 1 --all

…to conclude all available courses in any now-ended term.

[SethBattis · Accepted solution]

So, I think it's worth winding back to _why_ I was asking this question: because I was pulling "available" courses from the API and a bunch of old courses were showing up. Turns out that the _core_ issue was that those old courses had, apparently, been create _before_ I had set "Restrict students from accessing courses after end date" at the account level, so those old courses didn't inherit that setting.

To be honest, I'm a little skeptical about that assessment since, a) I went through and set a bunch of reasonable settings (including, IIRC, _that one_) before creating _any_ courses in our instance. But whatevs: it's clearly water under the bridge now. And new courses seem to be created with that setting (regardless of my course template setting: if the restriction is turned on at the account level, it _does_ apply to newly create courses, whether or not the template has the restriction set).

Which means, in theory, that this is now a "set it and forget it" situation: the old courses become wholly inaccessible to students when the term ends (barring any individual configuration of courses) and while faculty can still access them, they are no longer "available".

Which means that there should be _no_ end of term procedure.