Restore Delete Course without Manage SIS Data Requirement

0 Likes
(9)
Comments from Instructure

This was resolved as a Known Issue.


~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:

  1. 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.
  2. 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.
  3. 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.

8 Comments
Stef_retired
Instructure Alumni
Instructure Alumni
Status changed to: Moderating
 
Stef_retired
Instructure Alumni
Instructure Alumni
Status changed to: Open
 
ryan_milczarek
Community Member

We are seeing a similar process break caused by the recent permission restructuring for Manage Courses - Delete and SIS Data - Manage.

We have quite a few college admins who manage their colleges via sub-accounts off our root account.  They are assigned the Account Admin account role at their Sub-Account level so they can have some autonomy over their colleges without getting full root account access.

They commonly would need to restore a deleted SIS course to export content from the older course to import into courses for new terms.  Once they have everything they need, they would again delete the SIS course so that our interface is not clouded with courses from 5 terms ago.

Since the recent permissions changes, they can no longer delete these courses since the Manage Courses - Delete permission is now tied to the SIS Data - Manage permission for courses containing SIS IDs.  We do not want to give these admins the SIS Data - Manage permission for similar reasons you mentioned, and even if we did want to, it is not an available permission setting in the Sub-accounts.  We also do not want to give them root account roles that would give them the ability to affect changes to other colleges users and courses.

Now, requests to delete SIS courses that have been restored in the manner, or any other request to delete an SIS course (again, some of the same reasons you mention) now must be sent to the main system admin to complete, making this process inefficient and adding to the system admin's workload.

 

cesbrandt
Community Champion

We noticed that it also doesn't matter if you give a user Account Admin on a subaccount because, as you pointed out, SIS Data - Manage can only be assigned at root.

As a "temporary" solution, I wrote a basic third-party deletion script that allows authorized users to delete any non-protected shells using a service account.

I understand why they made this change, but I also feel it was a bit hasty in design. For something like this, there are always exceptions to the rule that need to be able to be accounted for. It's my hope they, at least, give us the option to either override the requirement for specific users or disable the requirement entirely.

dtod
Community Contributor

Same here. Major pain for me as the root admin. Our integration recreates deleted courses, so if a course has been fouled up by an instructor, sometimes a sub-account admin wants to delete the course and allow the integration to start again from scratch. But yes, just general clean-up requirements mean that they should be able to delete SIS-created courses, but giving them Manage SIS Data is never going to happen.

milesl
Community Contributor

I've been contacted by 3-4 department admins in the past week asking why they can no longer delete (or reset--I assume this was also impacted by the permission change) courses.

I hadn't realized that "manage sis data" can only be granted at the root level. We absolutely cannot hand that out, but I would like to have a better solution than telling everyone to email us when they need a course deleted.

dtod
Community Contributor

Per my CSM, this has been noted by development and they should be fixing in a future release.

Stef_retired
Instructure Alumni
Instructure Alumni
Status changed to: Archived

Thanks to everyone for contributing to this thread. Our engineers considered this a bug, and it's now been resolved. Please refer to  Allow subaccount admins to delete SIS courses with...  for details.