Javascript to hide role in +people if FERPA training not completed

[patfm]

We are trying to see if there is a way using JavaScript to prevent Teachers from adding TAs and Graders to a course unless they have gone through FERPA training.  Our Registrar keeps a database table listing all staff, students who have completed FERPA training and we were thinking of adding an attribute to Canvas USERS either using an unused field like BIO or a custom field to hold that data -'Y' if FERPA trained -- using an existing SIS  batch job that is run 3 times a day.  We are wondering about the feasibility of using JavaScript to check that field and only show the GRADER or TA role in the dropdown of the +People tool if the student selected has the FERPA flag set to 'Y'.  We would love to hear from anyone with ideas for implementing this.

[chriscas · Accepted solution]

Hi @patfm,

First off, just wanted to let you know I'm going to move this post over to the developers area of the community, where you might get some better eyes on the tech side of things.  Hopefully you don't mind.

Onto the actual question you posed...  My initial reaction to this would be to perhaps suggest creating a different/custom role for teachers that have passed your FERPA training vs those that have not.  You could let theFERPA role add people in the TA category, and deny that for the non-FERPA role.  Looking at your screenshot, this seems like a possibility, but it would depend on whether you'd want to deny adding the undergrad ta too.  If it's okay to deny adding people with that role too, I'd highly recommend this route as it would be the most secure, and not rely on any JavaScript.  This does assume that you can customize your SIS batch job, which I think is likely based on your description.

I'll wait to see your response to the above before going into what I think the caveats of the JavaScript approach would be. as it might become a time consuming and lengthy post.

-Chris

[chriscas · Accepted solution]

Hi @patfm,

First off, just wanted to let you know I'm going to move this post over to the developers area of the community, where you might get some better eyes on the tech side of things.  Hopefully you don't mind.

Onto the actual question you posed...  My initial reaction to this would be to perhaps suggest creating a different/custom role for teachers that have passed your FERPA training vs those that have not.  You could let theFERPA role add people in the TA category, and deny that for the non-FERPA role.  Looking at your screenshot, this seems like a possibility, but it would depend on whether you'd want to deny adding the undergrad ta too.  If it's okay to deny adding people with that role too, I'd highly recommend this route as it would be the most secure, and not rely on any JavaScript.  This does assume that you can customize your SIS batch job, which I think is likely based on your description.

I'll wait to see your response to the above before going into what I think the caveats of the JavaScript approach would be. as it might become a time consuming and lengthy post.

-Chris

[patfm]

Thanks, Chris,

I appreciate your quick feedback.   I need to clarify a couple of things.  We already have borrowed some JavaScript to limit the possible roles that a teacher can add to a course -- currently they can only add Observer and Designer.   Those are considered roles that don't require FERPA certification.  So we know we can limit the roles a Teacher can apply.

What we want to do now is to ALLOW the additional roles of Grader and TA to be selected only if the person selected by the instructor has the FERPA attribute in the USERS API set to TRUE.  I should have used a screen shot of what an instructor sees when they use the Add People tool. (I had done screenshot of what I see as an admin.)  So you see in the screen shot below that the JavaScript is removing the view of the other roles.  Now we want to add some 'intelligence' to the JavaScript so it can actually check on the ID of the person to allow additional roles to show in the dropdown if the attribute of FERPA is set to TRUE.  If not, only Observer and Designer continue to show.   We know some schools have built an LTI tool for Teachers to use when adding 'people' to a course to control  the roles they can assign, but we don't have an LTI tools environment so would like to know if this is possible through JavaScript.

[chriscas]

Hi @patfm,

I'm sure what you're trying to do with JavaScript is technically possible, but I was suggesting perhaps a slightly different path that would be more supported by Instructure for this.  I'd still suggest this alternate approach if it's possible, because the permissions/controls would be on the back-end instead of doing front-end modifications (which are basically unsupported).

When doing this with JavaScript, it's going to be able to by bypassed pretty easily by users who want to get around the restrictions you set, and the Canvas API (which is accessible to all users) will not be bound by these restrictions at all.  I believe you'd need to store the info as custom user data, then retrieve that data with your JavaScript and take the appropriate action to add/remove roles.  I don't know how long the retrieval call takes for this API (hopefully it's fast), but you may need to account for that if the user is very fast with their mouse clicks and the API is somewhat slow.

Someone else may come along and be able to provide more details, but hopefully this helps a bit.  You may also want to post the JavaScript code you're currently using so others can see where modifications for this functionality could be made.

-Chris

[seanbeirnes · Accepted solution]

Hello @patfm,

I second that JavaScript is not a great solution for this. Users can easily and quickly disable your custom JavaScript from loading if they know where to look, and in such case, the user would be able to see all the options to add a Grader or TA whether or not they completed the FERPA training. Removing or disabling a button in the UI with JavaScript also does not prevent someone from still accessing the API to complete that action, it just puts it out of the reach of some users and makes it only slightly more annoying for those who know how to get around it. 

The solution @chriscas provided with implementing a new user role is a much safer (and reliable) option. However, you may want to consider what the implications of this may be for your enrollment process if your institution has an automated enrollment script or tool that syncs your SIS system with Canvas. Adding another role may cause other headaches down the road when trying to get things to sync up.

I will propose another option: Handling this external to Canvas. You may consider disabling the "add user" permission for the teacher role and having the "add user" requests sent to a central source like a department support email, web page, or form. For example, when the email account receives a request, you could add the user SIS ID, Course ID, and Role to a spreadsheet and, maybe every day or so, convert it into a enrollments.csv SIS Import. You could also compare that spreadsheet with the data the Registrar has using Excel or with something like a Python script to help automate the process. You could also set up a Google Form or Microsoft form where instructors submit the request and then have a Python script do the FERPA training status lookup for you and perform the enrollment via the Canvas API (or SIS Import). If you are a Microsoft Institution, you may also want to look into Power Apps as a low code solution (instead of using Python) to automate this process with a Microsoft Form.

I hope this helped!

[patfm]

Thanks Sean,

Great suggestions.  I suppose ultimately the best solution would be an LTI tool, of which there are several that other schools have created.  I like your semi automated approach of a Google form or Microsoft form.  Being a Google school, we would probably go the Google form route.  That may be a great interim solution until we can get an LTI deployment service stood up at our school or get a third party to implement this for us. 

We appreciate your and @chriscas warnings about a JavaScript solution.