LTI section identification

[Alex-Jordan]

Perhaps this should be rejected; it may be specific to D2L Brightspace.

But these are local changes we have so that when student WW accounts are created using LTI, their sections from the LMS will carry over into their WW account. Let me know if one or both of these are wrong for Canvas or Moodle, and I will modify or withdraw the PR.

Note: this is not useful when all students in a D2L course are from the same section. However it is common here to cross-list multiple sections into one D2L course. So these settings help us sort students in the one WW course based on their section number.

[somiaj]

I think each LMS might do this different. In Canvas I have to specifically tell canvas what variable to send with the section value, by adding a custom variable, which I just call section, section=$com.instructure.User.sectionNames. I then have to write a custom function to get this value. I wonder if the solution to your problem is just to write a custom function for the course.conf files to use. This is what I use.

# Add section to the LTI user information
$LTI{v1p1}{modify_user} = sub {
    # The self object from LTIAdvanced.pm
    my $self = shift;
    # The user object to be modified
    my $user = shift;

    $self->{section} =~ s/[\[\]"]//g;
    my @custom_sections = split(/,/, $self->{section});
    my $custom_section = $custom_sections[-1];
    $custom_section =~ s/MATH333//;
    $user->{section} = $custom_section;
};

[Alex-Jordan]

I was happy to get this working (originally for LTI 1.1, and years later for LTI 1.3) without the modify_user subroutine. That is, to get the section identified directly. I think modify_user could be good for other things. I suspect the context_label value we used with LTI 1.1 is a bit ad hoc, and like you suggest, it may just be different for each LMS what to use.

But for LTI 1.3, I am a little hopeful that course_section_sourcedid is somewhat standard. Maybe it's not always in the format people would expect. And maybe it's not even there (because the spec says it is optional). But it would seem to be the "right" thing in the spec to identify a section. This is replacing custom#section or custom_section which don't appear to be a thing with LTI 1.3. I'm guessing that was just a shot in the dark emulating what was there with LTI 1.1.

[Alex-Jordan]

I just checked the LTI 1.1 spec, and what I am proposing to change here (context_label) also looks like it ought to be the right thing. Of course an LMS might not always be set up to use this as I'm reading it should be used. But are you willing to check what happens if you change lib/WeBWorK/Authen/LTIAdvanced.pm as I have it here, and comment out your modify_user subroutine? If you let the LMS update user data, then you could see the effect on the "section" for a student the next time they enter. Maybe you could only nullify the modify_user subroutine for one of your own classes?

[drgrice1]

Yeah, the section and recitation were added to emulation LTI 1.1, although the specification does allow for custom claims and that is the equivalent of a custom key for LTI 1.1. See https://www.imsglobal.org/spec/lti/v1p3#custom-properties-and-variable-substitution. Custom variables for LTI 1.3 can be set in the LMS in the external tool definition.

I am not sure that this should be changed for LTI 1.1. It is documented how to use a custom field to pass this at https://webwork.maa.org/wiki/LTI_Authentication_(for_WeBWorK_2.18_or_newer). If this is changed then the documentation will also need to be updated.

[Alex-Jordan]

If the LTI 1.3 part of this might be good, I could just drop the LTI 1.1 part. I'm curious to see if the LTI 1.3 change does good things overall or if it just happens to work well with our D2L instance.

[Alex-Jordan]

I changed this to only change the section setting for LTI 1.3, and leave LTI 1.1 alone.

[drgrice1]

I was actually going to tell you to leave the 1.1 change in. Although that has been documented on the wiki, I never really thought that was a very good mechanism. It really only works if you have per course tools and add a custom variable. At my institution I have a single external tool set up for all courses (a Canvas admin set this up for me), and custom variables really don't give per course information with that. I am just not certain how useful the custom variable thing was, and I think that is something that would be better handled using the modify_user subroutine approach anyway.

I also just generally didn't like that something like that is hard coded in the way it was.

I think that an even better way to go would be to have a setting as we do with preferred_source_of_username for section and recitation. (Although I would like to drop recitation entirely from the code really since you can actually use section to do both.)

[somiaj]

I like both the idea of adding a preferred_source_of_section idea (Then the modify_user function is only needed if it is needed to be mangled, such as in my case where the string I get is ["003"]). I also second @drgrice1 suggestion, remove recitation, section should be enough for that.

[Alex-Jordan]

I brought back the change to LTI 1.1 for section.

Moving to a "preferred source" and removing recitation entirely feel like larger projects that could be done separately, later. Before removing recitation, I suggest we query the Runestone WW hosting database to see if there are any active use cases we should still consider supporting. Even if it's not being used to classify students into true recitations, people might be using it to categorize students for some reason beyond their section.

[drgrice1]

If we keep recitation, then we should add both a source_of_section and source_of_recitation. There should not be a preferred prefix on these because there will definitely not be fallback options to go with these. To be frank, the fallback_source_of_username should have never been added, and there should only be source_of_username (also without the preferred prefix). That really doesn't make sense and stems from flawed configurations/setups to begin with.

Note that what I meant by the section can be used for both is that you could set section to be something 5,10 for a user that is in section 5, recitation 10. To deal with that you would of course need to use the modify_user subroutine.

I don't believe that there is any LMS that directly support recitations. Section categorization is as far as any other system out there ever directly supports.