[ARCHIVED] Why can't custom roles work the same regardless of enrollment method?

[pchaney]

Hi Folks,

I created a custom course role because we needed to allow the role elevated permissions to manage users in a specific sub-account. It works as intended as long as users are enrolled via the UI, but it doesn't if the users are added via SIS Import. Account Roles for the sub-account have the same issue.

After submitting a Canvas Support request, I was informed this behavior was "by design".  If so, this is a bad design. Custom roles need to work regardless of enrollment method or why have them? I submitted an idea to change this design, but as one of the smallest and busiest user groups, Canvas Admins are not likely to get enough votes to make it happen.

I am  asking Canvas Admins to consider viewing this idea and voting for it:

#Created (custom) subaccount roles should behave the same, regardless of user enrollment method

Thanks,

Paul

[guilera]

Good luck as we would like this feature as we are planning to move to Canvas!

[jsavage2]

Hi Paul,

Can you provide a concrete example of what doesn't work, and the permissions for the role you created? You may want to take a look at the flags on the SIS import (e.g., "Process as UI Change") and see if there isn't a combination of import settings and permissions that gets you where you need to be.

If you have a particular subaccount that needs to be more independent of the central SIS and Registrar (say, for things like Continuing Ed and certificate programs), you might also consider moving away from the SIS Import proper for those courses and leveraging the Users and Enrollment APIs, which allow you to automate data transfer without flagging records as SIS-managed.

In many ways, this suggestion runs counter the purpose of SIS integration in the first place, and why institutions choose SIS Import instead of API Import. SIS import tells the system that you want certain information to be managed outside of Canvas, and Canvas should defer to the external source. At most institutions with SIS, the SIS is the system of record, and overriding it requires permissions and causes headaches. Instructors and subaccount admins can do things *in addition to* what's in the central SIS, but not *instead of* what's in the SIS.

There are certainly situations that require manual intervention and judgment calls, but usually those should be documented and go through the central LMS administrators where they generate tickets and audit trails, since for many students those decisions have implications for things like tuition, financial aid, scholarships, veterans benefits, visas, etc. not to mention FERPA and GDPR. 

At institutions I've been at, instructor might, for instance, be allowed to give access to a course to an "informal" auditor or a TA or colleague not officially listed as a co-teacher (although there are FERPA considerations in some cases), but would never be allowed to remove a student from a course that the student was officially registered for a course. Nor would s/he be allowed to add back a student who officially dropped, or was removed by something like an administrative hold. That would be need to be handled by the Registrar. If the SIS isn't authoritative, why have one?

There are definitely situations where managing SIS data can be cumbersome, but changing the basic functionality seems like throwing out the baby with the bathwater, particularly when there are other user management APIs already in place.

[pchaney]

Hi Jay,

Thanks for responding.

I've worked with Canvas Support on this with the various import flags, and none of the flags tried worked, and when it was escalated, that was when I was told the behavior was "by design".

We currently have an older SIS system, with no API Imports or vendor SIS integrations, so all enrollments to catalog courses are handled via SIS Imports. We've also use SIS Imports to populate other Canvas shells, such as our Online Tutoring as well as diagnostic/remedial lab shells in Canvas, and have done so for years. At one point, we were able to assign special "Tutor" and "Lab Manager" roles with elevated permissions to manage students, all enrolled with SIS Imports.

We recently discovered the problem when we created online Student Advising support course with the custom "Advisor" role and "Coordinator" role. Approximately 1500 first-time-in-college students were assigned to "Advisors" and placed in respective Adviser sections. The Advisor role is a fairly restricted teacher role that doesn't allow content editing, while the Coordinator's role (also based off the teacher role) is to adjust section rosters as needed.  The problem is that everything works when students are enrolled in the UI but not via SIS Imports. We could manually add 1500 students via the UI, but these would be invitations rather than direct enrollments, and it's very time consuming when we are looking to automate this.

I don't understand your statement "SIS import tells the system that you want certain information to be managed outside of Canvas, and Canvas should defer to the external source."  SIS Import means you want your institution's information in and to become part of Canvas - it's no longer "managed by an SIS" (unless you export it again to the SIS). For what possible reason would you not want an Canvas user to be subject to the permissions of a Canvas role you created?  It's like SSO authentication vs. Canvas local authentication --- how you get access to Canvas may differ, but once you are in, Canvas should work the same for any authenticated Canvas user, regardless.

It really is this simple, stripping away all the reasons why institutions choose SIS Import, as opposed to API or UI enrollments, FERPA, audit trails, etc.  A custom role and it's permissions should work according to the assigned permissions, regardless of the way an enrollment is processed in Canvas. In this case, changing the basic functionality is not like throwing out the baby with the bathwater, if the reasoning behind the basic functionality is flawed - change the flaw in the basic functionality. 

If as an admin, the roles and permissions you define work only part of the time, it's a bug and it needs to be examined and corrected.

Thanks,

Paul

[jsavage2]

Hi Paul,

By “managed outside Canvas” I mean that the data is stored in the SIS and synced to Canvas regularly. When changes need to be made, they are made in the SIS and re-synced to Canvas so that Canvas always reflects the official system of record. Most institutions that use SIS Import have scripts running to do this anywhere from once a day to every few minutes.

The assumption (...although of course we know what they say about assumptions) is that overriding the official record *should* be difficult and *should* require a very high level of authority (specifically the root account-level “manage SIS Data” permission).

Once the data are extracted from your SIS, though, there’s no requirement to use the “SIS Import” endpoint, specifically, if you don’t want the behavior associated with that endpoint. Instead of pushing the csv files directly to /api/v1/accounts/:account_id/sis_imports, you can push the data to, say, /api/v1/courses/:course_id/enrollments

For instance, this is a little Perl snippet that I keep on hand for just these kinds of situations, where I want to bulk load some one-off enrollments based on SIS identifiers, but I don’t want the full-on centralization that comes with the SIS import proper. That lets us keep everything fully synced to the SIS for normal courses, but still create things that aren’t tightly-coupled to the SIS for special cases. It takes a tab (or space)-delimited file with student IDs and course IDs, and enrolls the students in the specified courses. It's honestly longer than it needs to be, but I've never bothered to refactor it:

#!/usr/bin/perl

use warnings;
use strict;
use LWP::UserAgent;
use JSON;

my $base_url = "https://[YOUR CANVAS INSTANCE]/api/v1/";

my $account_enrollment_endpoint = $base_url . "courses/sis_course_id:<course_id>/enrollments";

my $ua = LWP::UserAgent->new;
$ua->default_header( 'Authorization' =>
    "Bearer [YOUR TOKEN]"
    );

foreach (<>) {
    chomp;
    my ($user, $course, $role) = split/\s+/;
    print "$user\n";
    my $enrollment_endpoint = $account_enrollment_endpoint;
    $enrollment_endpoint =~ s/<course_id>/$course/;
    print $enrollment_endpoint, "\n";
    my %params = (
        'enrollment[user_id]' => 'sis_login_id:'.$user,
        'enrollment[role_id]' => $role,
        'enrollment[enrollment_state]' => "active",
        'enrollment[notify]' => "false"
    );
    my $r = $ua->post($enrollment_endpoint, \%params);
    unless ($r->is_success) {
        warn "Could not retrieve user $user: " , $r->status_line,   "\n", $r->as_string(), "\n";
    }
    my $enrollment = decode_json($r->decoded_content);
    print "Enrolled " . $enrollment->{user_id} . ":" . ($enrollment->{sis_user_id} ? $enrollment->{sis_user_id} : "Null") 
                      . " in " . $enrollment->{course_id} . " as " . $enrollment->{role_id} . "\n";
}

__END__
CSV FORMAT:

nunya@biz.ns    your_course_id_xxxxxxx    42

ROLES:

teacher   = 43
observer  = 46
student   = 42‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

[pchaney]

Hi Jay,

I imagine we are like most institutions using SIS Imports - using automated scripts to upload CSV files at regular intervals. It's a proven reliable method with our older SIS system and we'll keep it until our SIS system is upgraded in the next few years. We know we could probably do enrollments via the API, and that may be a workaround, but why workaround when what we have works great except for this quirk?  Fix the quirk in Canvas.

It goes back to my point - SIS Imports, the Enrollment endpoint, and  the Canvas UI are all just methods to ingest enrollment data into Canvas LMS. While the two systems may have interfaces to connect and transfer data, the two systems themselves are separate, and controlled separately according to their own administrative interface.  Importing data is a one way process between two systems based on the how the client desires to send the data; it becomes part of Canvas and is no longer SIS data, so Canvas roles and tools should work uniformly within Canvas. Once a Canvas user is enrolled into a Canvas course, shouldn't a Canvas custom role behave the same regardless of enrollment method (just as standard roles do)?  

Using the enrollment API works for you now, and for me it may be a way around a bug, but what happens when an update causes Enrollments API to the have a similar issue?  Or maybe not enrollments, maybe User accounts added via UI begin to behave in Canvas differently than Users imported by User API?  I'm not saying that it's easy for Instructure to continually make sure three different enrollment methods are coded write all the necessary data to the various tables and fields, but it needs to start happening for uniformity and predictability of Canvas behavior.

Well Jay,  I don't think we will ever agree on this, but thanks for your responses and for posting the handy script. We've been doing a little API scripting within our workflow web applications, and I'm sure we will use API more when we get our new SIS. Best of luck!

Thanks,

Paul

[jsavage2]

Hi Paul,

I think maybe I'm misunderstanding. As I understand it, Canvas has a specific "Manage SIS Data" permission that can be assigned, and that users who have this permission can manage (i.e., change) data imported from the SIS, and those without the permission can't. 

This seems pretty straightforward, and entirely inline with the way permissions are provisioned for Canvas roles in general.

It's a very powerful role, since it affects not just enrollment data, but student identifiers. And like other powerful and potentially destructive permissions (like Masquerade and the basic Import SIS Data permission itself), it is restricted to very high-level account admin accounts.

That follows basic InfoSec principles of inheritance and least privilege: once we accept that SIS Import is restricted to the top level because users exist at the top level, it doesn't make sense to devolve Manage SIS Data. If the restricted data can be overridden by users with lower privilege, the restriction isn't very strong. (I would personally argue that there's a case to made for letting SIS Imports happen at the subaccount level, but that's a different discussion...)

In terms of tools working uniformly, I think we have to start from the perspective that multiple options for data integration and management don't exist just to create complexity and confusion, or to create choice for the sake of choice; they exist to allow and enable enable different use cases.

SIS Import isn't just "how the client desires to send the data," in the abstract. It's the particular way clients choose to send data, in preference to other options, *because* they specifically and explicitly want the data to be identified as SIS data and assigned a specific and explicit SIS import ID that can be used for audits, and they want to specifically and explicitly invoke the permissions and restrictions we're discussing here. 

[pchaney]

Hi Jay,

That is exactly the problem, in a sub-account you can create a custom course role ('Coordinator') or even account role with the "Manage SIS Data" permission assigned (actually for troubleshooting we gave all permissions), and then assign the "Coordinator" role to the user in a course. When you add a few students to the course via the UI, it the Coordinator role's permissions works as specified. Next, when you add students to the course using SIS Imports, the Coordinator role doesn't work with these students, while still working with the student added by UI. The Coordinator role needs to work with either students regardless of enrollment method.

My guess is that students enrolled by SIS Import aren't writing to same fields in a table(s) as with UI enrollments or there is some database restriction which doesn't occur in UI added enrollments. I think there's missing piece of data that the Coordinator role can't find when the Coordinator attempts to edit a SIS Imported student using the UI's flyout menu (to change sections, remove, deactivate, etc.)   Possibly when enrolling a student using the UI, the sub-account information is added, allowing the People manager's code to correctly map to the sub-account containing the Coordinator role. 

I'm going to test putting the custom Coordinator role in the root account to see if that works. 

Thanks,

Paul