~2 updates ago the permission for delete courses with SIS data was modified to require the permission to manage SIS data. SIS data is often used as a cross-system identifier, so the ability to modify it should be heavily restricted. However, this should not prevent users from being able to do other things with a course using an SIS ID, not even deleting them.
The idea is pretty straightforward: undo this change! Or, at the very least, make it a permanently optional change.
Here's our situation.
Imagine a student completes an LTI assignment. The instructor unknowingly modifies the SIS ID, likely through some "fat fingering" when modifying the course title or something, then requests a grade sync from the LTI. Well, the LTI sees the new SIS ID and syncs the grades that were submitted with it, giving that student a 0, instead of the 98 they actually earned.
Why would this scenario even come up?
Some of our faculty are actively involved in the development of curriculum, requiring they be granted a measure of access that ordinarily wouldn't be given to instructors. Due to our usage of LTIs that are dependent upon SIS IDs, we developed a third-party course copy system that will use the Canvas API to generate shells, assign SIS IDs, and do a number of other things to save us the hassle of having to do so much manually. This means that nearly all of our shells, whether they be developmental, testing, or live, have SIS IDs assigned to them. However, almost no one should be manually touching these values, let alone able to do so.
Here are a few examples of circumstances where they should be allowed to delete the shells:
Development of a course ran late and a live course needs to be replaced
There are more complicated LTI-related reasons why we can't use the course reset function.
Development of a course was dropped/drastically changed
Why keep the course shell if it's gone in a different direction? Just muddies the course list.
Testing of a course needs to be redone with updated course
Some LTI providers charge per course, only allowing test SIS IDs to be reused, so we can't just assign new ones every time we need to restart testing.
I understand that we don't operate like most institutions. In some ways we are seen are backwards while other ways are considered idealized, if not practical. I also can't imagine we're the only ones that manage our SIS IDs externally.