Test new D2L LTI 1.1 to LTI 1.3 migration path

[mattdricker]

D2L has begun automatically migrating existing LTI 1.1 tool link to LTI 1.3 if there is a matching LTI 1.3 tool installed. See this doc for additional info: https://community.brightspace.com/s/article/Brightspace-Legacy-LTI-to-LTI-Advantage-Migration-Plan

Our current guidance on upgrading Hypothesis to LTI 1.3 in D2l assumes that all links created previously with the LTI 1.1 version of Hypothesis will continue to use the LTI 1.1 tool.

Given that D2L is upgrading older links automatically after a course copy, and will be providing a future migration trigger for older courses, we will need to test what impact their link migration has on Hypothesis assignments.

[mattdricker]

Issue raised by user: https://app.hubspot.com/contacts/6291320/ticket/1193568333

[marcospri]

Docs in to https://documentation.brightspace.com/EN/integrations/ipsis/LTI%20Advantage/lti_migration.htm

[marcospri]

I've only tested the case using course copy but I reckon any other method of upgrading will be the same.

In D2L the tool-guid is the consumer key. This is a bit surprising and counterintuitive as the GUID is no longer an institution-wide identifier but only identifies one particular install. This is not new but relevant for the upgrades.

I reckon for D2L we've been saying that because D2L didn't have an upgrade path and all this GUID business schools should keep both versions around.

For upgrades to work both versions need to be installed at the same time, and the links move from one to another, this is different from other LMS where the tool itself gets upgraded.

With the new link upgrading feature, both GUIDs are sent on launch for upgraded links but it's not clear which one we should choose:

• Use the new (1.3) GUID. This will keep the assignments being H ones but it will no longer point to the old GUID. This is just moving everything to the new tool without backward compatibility, at least for everything GUID related. This is probably fine for course copy (the course/groups would be new anyway). This works now, no need to deploy any changes.

• Use the old one. This seems like the obvious choice at first glance but what happens here is that the LTI1.3 tool that has its new GUID gets launched with a different GUID (the one from the LTI1.1 tool). This trips our "no tool-guid changes" protection.

  We could special case the tool-guid change warning to avoid this case. Or we could allow editing the GUID in the admin pages (potentially breaking any existing 1.3 assignments).

Not sure what the right call is here. If a school has already been using 1.1 and 1.3 I reckon we should just use the new GUID. If this happens in a school that it's just installing 1.3 there might be some value in figuring out a procedure to use the old GUID.

[marcospri]

With the GUID changes discussed here this doesn't have an easy solution.

A proposed alternative would be to:

• Abstract "school_identifier" or similar as a concept
• Default implementation just returns application_instance.guid
• For D2L we balance these mulitple GUIDs to do the right thing in each case.

This work could also help an hypothetical move away "GUID" to something else to allow more flexibility there.

[marcospri]

@darylhedley Not sure if it was evident by the writeup above but this is a big chunk of work. We should discuss slotting this into a sprint.