[ARCHIVED] Hiding "Remove from Course" option

[shane_ohara]

Hello everyone,

We have run into a situation with running enrollments via API where Teachers have the ability to remove a student from a course in the People area. When enrollments are run using SIS, Teachers do not have the ability as the "Remove from Course" option is hidden from view. Here's an example of what a Teacher currently sees because of our API enrollment method:

What we would like to do (other than disabling the permission for "Add/Remove students for the course" because there is a need for manually adding/removing) is to use Javascript to hide "Remove from Course". However, this is proving tricky as the ID value for it is different per user. Right now, I can use (as an example).....

$("a#ui-id-9.ui-corner-all").hide();

...to hide "Remove from Course" on a per user basis. The value "ui-id-X" is assigned by the system, so I am not sure how I would write it to grab all the IDs and hide when the caret is clicked. Any thoughts for this rookie?

Thanks!

Shane

[kona]

I'm not sure of the answer to this question, but due to the technical nature, I'm going to share it with the Canvas Developers​ group to see if they can help!

[jenn_stevens]

 @shane_ohara ​, good news! It's a bug and the fix will be out in the Production release this weekend! Here's the snippet:

Permissions

Course Sections

Users cannot remove a student from a course section unless the users have the Add/remove students from the course permission.

Explanation: When a user was given the permission to Add/remove other teachers but not the permission to Add/remove students, the user was able to remove students from the course using the Sections page in Course Settings. Canvas code has been updated to only allow users to remove students from a course section if the user have the permission to Add/remove students for the course.

(We're still trying to figure out why some of our students that were added via SIS are showing up as added via API, but that's a problem for another day. At least the profs cannot delete them now!)

[shane_ohara]

Unfortunately, this won't solve our issue. Our students ARE added by API, therefore the teacher permission is doing exactly what it is supposed to do - allow removal of students. We need to hide or disable this option.

[garth]

 @shane_ohara ​ this is probably obvious, but can you take away the course priv:

• Add/remove students for the course

Or if the courses where you add students by API can be isolated in their own sub-account, could you create a new course level role for teachers, then take away the add/remove priv, so it only effects those courses?

I haven't studied the difference in the json data between an enrollment / course that was added by SIS vs. API.

It seems odd that there would be different behavior.

Have you confirmed that there aren't different course roles in play here?

[shane_ohara]

 @garth ​, we looked at the privs, but they are not granular enough to set "add" to on and "remove" to off. We have a number of sub-accounts (each is a college at the institution), so setting sub-permissions wouldn't work either. Disclaimer: we have a unique window of time in which some faculty will add students to a course as a quick look prior to enrollments.

We reached out to support to get an explanation between SIS and API. SIS is the only method that locks the remove option. API is much like a manual enrollment.

I do appreciate your reply.
Shane

[garth]

Can you create a custom SIS import file, and leverage the import process, instead of using the API directly?

My thought is: if you are using the API you must have a list of users somewhere already, would it be difficult to format that list into an import file and push it through the SIS Import process?

I have done this for testing, and for custom one-off courses: importing custom small batches of users to a course.

Just an idea.

I am intersted to know what response you get from Support, please post back : )

[shane_ohara · Accepted solution]

Mystery solved - we now have a function to handle this now and didn't need to touch a single priv or rethink out enrollments via API. I am happy to share it with you offline. Props to the IC team for assisting to get this working right.