Update LTI Tool Launch URL in Assignment

[d_tan]

The scenario is we have two Canvas environments, the production Canvas, and a test environment which is automatically refreshed every 3 weeks base on the production data.

When our users setup external tool assignments on production, pointing to our LTI tool, the launch URL is stored within the assignment.

When that data is migrated to Test environment, which is pointing to another launch URL, the value stored in the assignment is not automatically change when we modify the tool configuration.

This is because the linkage between tool configuration and assignment is via the launch URL rather than an identifier or ID. So when the lunch URL is changed in the tool config, essentially the tool is no longer exist from the assignment point of view.

My question is - is there an efficient way to update the launch URL stored in the assignments using Canvas API, other than looping through the course list, getting all the assignments and examine them one at the time to decide whether the change is required?

Thanks

Doug

[tyler_clair]

Hi Doug,

The cascading change will only work if you have set the tool up at the account level. If its this way you can edit the app launch URL in your test or beta environment and it will change it everywhere. So you could script it through the API (https://canvas.instructure.com/doc/api/external_tools.html#method.external_tools.update) to make the change and schedule it to run in accordance to the update schedule of beta and test. If you set it up on a course-by-course bases you will have to do the looping method.

Best,

Tyler

[d_tan]

Hi Tyler

Thank you for your reply. The tool is configured at the account level. And what your are saying is not wrong.

When the tool config is changed at the account level, assignments created after that point will be pointing to the new launch URL. However my issue was on the already existed assignments, they will still be pointing to the old launch URL. At least that is what our testing shows.

Thanks

Doug

[cesbrandt · Accepted solution]

Edit: Seems I got a big ahead of myself. I just did an isolated test intending to determine exactly which fields are updated and which aren't. I'll blame my original observations on our high use of LTIs.

So, testing each individual field, it is only the URL that does not update. Seeing that, I took a closer look at the API and found we can trace the links back, however, you would still need to check every assignment and module item to determine if they are connected.

For module items it would be the content_id of the item. Assignments a s bit trickier. You'd need to use the url of the assignment to run another API call to get the id of the external tool.

Still, to run this would simply be, well, excessive. First we'd have to get a list of all courses on the server, then all their module items and assignments, then filter for only those attached to external tools, then filter for those matching the external tool that was just updated, and finally update them. It seems far more feasible for us to do it as a weekly/daily CRON, instead of a reactive process. There's simply too much that would need to be done at once.

Original

I've noticed the same thing with our LTIs, though it's not limited to the launch URL.

From what I've observed, it appears that the selection of the LTI as the submission method actually duplicates the LTI configuration and attaches it to the assignment, completely separate from the LTI configured at either the account or course level. To update the assignment to reflect any configuration changes to the submission method, the LTI needs to be reselected.

In the case of updating the launch URL but not any other configuration information, simply changing the URL in the assignment in addition to the App would fix it, but since the other configuration information can't be modified from within the assignment, the updated App has to be reselected as the submission method.

Further, this also appears to be the case for module item LTI links, also.

The only logical reason I can see for this is for historical documentation. All the configuration data is identical to when it was used. However, for any LTIs, this is troublesome as older configurations tend become invalid and cease to function.

Assuming the concept I came up with from my observations is accurate, this seems like it would be better served as an idea request. I, honestly, have no clue how we could go about updating corresponding assignments and module items as an external process. We would need to use JavaScript to listen for App update submissions and then pour through all assignments and LTI module items on the server just to find those that would be linked to the LTI that was updated. Even then, if I'm correct, we wouldn't be able to confirm that it is linked because the configurations would be duplicated, not linked.