Assistance Needed: Handling Resource Link ID in LTI 1.3 Migration

[Zohaib Akram]

Dear Dr. Chuck and Tsugi Developer Group,

I hope this message finds you well. I'm reaching out to seek your expertise and assistance regarding an issue I've encountered while migrating existing LTI 1.1 links to LTI 1.3 within Canvas LMS.

As part of the migration process, Canvas sends LTI 1.1 transition claims, including user_id, oauth_consumer_key, oauth_consumer_key_sign, and resource_link_id, in the launch data. While I noticed that the Tsugi codebase handles user_id, oauth_consumer_key, and oauth_consumer_key_sign using the LTI11_TRANSITION_CLAIM, I observed that resource_link_id is not handled by the existing code.

Here's a snippet of the relevant code in LTIX.php:

}

Given the importance of resource_link_id in associating existing records with new LTI 1.3 identifiers, I'd greatly appreciate your guidance on how to handle this parameter effectively within the Tsugi codebase.

Here's an example of the data for the https://purl.imsglobal.org/spec/lti/claim/lti1p1 claim received from Canvas during migration:

Your insights into handling resource_link_id within the Tsugi codebase would be immensely valuable as I work through this migration process. Any suggestions or recommendations you can provide would be highly appreciated.

Thank you for your time and assistance. I look forward to your response.

Best regards, Muhammad Zohaib

[Charles Severance]

Zohaib,

Thanks for your very clear summary of the issue.   As I read the spec,

https://www.imsglobal.org/spec/lti/v1p3/migr#lti-1-1-migration-claim

It looks like resource_link_id is definitely an expected parameter here and the code just does not have it.

Does it work if you just change the code shown to look for a fourth value and include it in retval?

If it works after you make the change, I would love a PR.

I never had a good place to test link migration in Canvas - their implementation seemed a lot more complex than Sakai and Moodle and I did not have admin on a Canvas site to test it for Canvas.

So a tested PR from you is a great way to go.

/Chuck

On May 9, 2024, at 8:03 AM, Zohaib Akram <techniso...@gmail.com> wrote:

Dear Dr. Chuck and Tsugi Developer Group,

I hope this message finds you well. I'm reaching out to seek your expertise and assistance regarding an issue I've encountered while migrating existing LTI 1.1 links to LTI 1.3 within Canvas LMS.

[snip]

[Zohaib Akram]

Dear Dr. Chuck,

Thank you for your prompt response and for your insightful feedback on the issue I raised regarding the handling of resource_link_id in the LTI 1.3 migration claim.

I appreciate your confirmation that resource_link_id is indeed an expected parameter according to the specification. Your suggestion to modify the code to include this parameter in the retval is logical and aligns with my understanding of the issue.

I will proceed with making the necessary changes to the code as per your recommendation and include resource_link_id as a fourth value in the retval. Once I've implemented these changes and confirmed that they address the issue, I'll be sure to submit a pull request (PR) with the updated code.

Your encouragement to contribute a tested PR is greatly appreciated, and I'm eager to collaborate in improving the Tsugi codebase in this regard.

Thank you once again for your guidance and support in addressing this issue. I'll keep you updated on my progress and look forward to contributing to the Tsugi project through the PR submission.

Best regards,

Zohaib

[Zohaib Akram]

Dear Dr. Chuck,

I hope this message finds you well. I wanted to inform you that I have raised a pull request (PR) addressing the issue we discussed regarding the handling of resource_link_id in the LTI 1.3 migration within the Tsugi project.

You can find the PR at the following URL: PR #182

Please review the PR at your earliest convenience. I'm open to any feedback or suggestions you may have.

Thank you for your guidance and support throughout this process. I look forward to your review and any further collaboration on this matter.

Best regards,

Zohaib

[Charles Severance]

Thanks - I won’t get to this until Monday - I am racing this weekend.

https://www.youtube.com/shorts/yM_J_fln4No

/Chuck

--
You received this message because you are subscribed to the Google Groups "Tsugi Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tsugi-dev+...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/tsugi-dev/3e0b684a-7263-4a9b-b4db-7861001813a3n%40apereo.org.

[Zohaib Akram]

Thank you for your response, and I appreciate your prompt attention to the matter.

I completely understand, and there's absolutely no rush. Enjoy your weekend racing!

I'll eagerly await your review on Monday.

Thank you once again for your time and support.

Best Regards,

Zohaib

[Chuck Severance]

Zohaib,

Thanks for the PR - I reviewed it right away but it did not look right so I needed to take a longer look.   The PR is incorrect and I have left a review.

The way transition works if there is a resource_link_id in the transition claim (old) and it is different from the resource_link_is in the launch data (new) is not to say you are supposed to “redirect" all requests to the old RLID - but instead notice that there is an old RLID and if your tool at the new RLID needs to, it can do something like copy settings from the old RLID to the new RLID.

So I left a comment that the primary change need is to record the new RLID in the retval and let the tool figure out what to do with it later.  It is really a simple change like this:

                if (isset($lti11_transition->resource_link_id)) {

                    $retval['lti11_transition_resource_link_id'] = $lti11_transition->resource_link_id;

                }

Then you can add tool-by-tool code to notice this and do something.  Let me know if you want to revise your PR or let me just do this one?

Let me know if you have any questions.

Thanks so much.

/Chuck

On May 9, 2024, at 8:03 AM, Zohaib Akram <techniso...@gmail.com> wrote:

Dear Dr. Chuck and Tsugi Developer Group,

I hope this message finds you well. I'm reaching out to seek your expertise and assistance regarding an issue I've encountered while migrating existing LTI 1.1 links to LTI 1.3 within Canvas LMS.

As part of the migration process, Canvas sends LTI 1.1 transition claims, including user_id, oauth_consumer_key, oauth_consumer_key_sign, and resource_link_id, in the launch data. While I noticed that the Tsugi codebase handles user_id, oauth_consumer_key, and oauth_consumer_key_sign using the LTI11_TRANSITION_CLAIM, I observed that resource_link_id is not handled by the existing code.

Here's a snippet of the relevant code in LTIX.php:

}<Screenshot 2024-05-09 154523.png>

Given the importance of resource_link_id in associating existing records with new LTI 1.3 identifiers, I'd greatly appreciate your guidance on how to handle this parameter effectively within the Tsugi codebase.

Here's an example of the data for the https://purl.imsglobal.org/spec/lti/claim/lti1p1 claim received from Canvas during migration:

<Screenshot 2024-05-09 153249.png>

Your insights into handling resource_link_id within the Tsugi codebase would be immensely valuable as I work through this migration process. Any suggestions or recommendations you can provide would be highly appreciated.

Thank you for your time and assistance. I look forward to your response.

Best regards, Muhammad Zohaib

--
You received this message because you are subscribed to the Google Groups "Tsugi Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tsugi-dev+...@apereo.org.

To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/tsugi-dev/d5d6f11a-acfb-4f7e-b7f5-77c6538f6d8dn%40apereo.org.
<Screenshot 2024-05-09 154523.png><Screenshot 2024-05-09 153249.png>

[Zohaib Akram]

Dear Chuck,

Thank you for updating the PR with the following code: if (isset($lti11_transition->resource_link_id)) {

    $retval['lti11_transition_resource_link_id'] = $lti11_transition->resource_link_id;
}

If we notice that there is an old RLID and the tool at the new RLID needs to copy settings (settings column in the lti_link table) from the old RLID to the new RLID, wouldn’t this approach potentially break the old links as based on new RLID it will create a new link in the table with the old link setting? Specifically:

1. Result Table Records: Since the link_id is used in the result table, copying settings to a new link would mean that all result records associated with the old link would not be available under the new link.

2. Other Tables: Other tables that use the link_id would also be affected.

Please correct me if i am understanding it wrong.

Thank you once again for your support. I look forward to your insights on this matter.

Best regards, Zohaib