-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SE-4235] Add missing parameter processors code #150
[SE-4235] Add missing parameter processors code #150
Conversation
Thanks for the pull request, @pkulkark! I've created OSPR-5686 to keep track of it in JIRA, where we prioritize reviews. Please note that it may take us up to several weeks or months to complete a review and merge your PR. Feel free to add as much of the following information to the ticket:
All technical communication about the code itself will be done via the GitHub pull request interface. As a reminder, our process documentation is here. Please let us know once your PR is ready for our review and all tests are green. |
db253da
to
3c1a549
Compare
@pkulkark Thank you for your contribution. Please let me know once it is ready for our review. |
@natabene This is ready for edX's review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pkulkark @gabor-boros I left some comments in the code :)
Thanks @giovannicimolin. I've made the changes as per your suggestions. Could you take a look and let me know if it looks good? |
@pkulkark Code changes look good, were you able to test these changes and make sure they work as expected? |
@giovannicimolin Yup, I tested it on this sandbox. Everything works as expected. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
- I tested this:
- I checked the sandbox instance using the
staff
user. - Checked data from additional parameter processors were passed to the LTI tool.
- I read through the code
-
I checked for accessibility issuesNA -
Includes documentationNA (bugfix)
@pkulkark Thanks for the fix, this was missed when implementing LTI 1.1 support outside XBlocks for the Discussions epic.
@pkulkark Is this ready for a final review? |
@nedbat Yes, this is good for a final review. |
@pkulkark I just realized that squash & merge is not enabled for this repo. Can you squash your commits down to a single one following OEP-51? I can merge after that. |
This Adds back the parameter processors code logic that was missed in a recent refactor.
ed0b23f
to
1926299
Compare
This PR updates the lti-consumer-xblock version to a new commit that contains the backported fix from openedx/xblock-lti-consumer#150
This PR updates the lti-consumer-xblock version to a new commit that contains the backported fix from openedx/xblock-lti-consumer#150
@pkulkark @giovannicimolin - Hi, currently testing out the new xblock-lti-consumer 3.0.3 and tahoe-lti. Per the "how to test" instructions of tahoe-lti, I was wondering if this PR + Tahoe-lti will work only for Lti1.1 or also Lti1.3? |
@louis-s-29 Tahoe-lti only supports LTI 1.1 as far as I know. |
@louis-s-29 Parameter processors are currently not implemented in LTI 1.3, but they can be plugged in the LTI 1.3 launch handler along with the custom parameter support. Upon a quick check, the parameter processor code seems to be generic enough so that it isn't too complex to add support for on LTI 1.3. If you are going to work on adding support, let me know, I can help/guide you through the implementation process. |
The previous lti-consumer-xblock commit hash was pointing to a code drift branch which was backporting openedx/xblock-lti-consumer#150 to tag `2.4.0` Unfortunately, `config_id` duplicate errors started showing for one of the clients. Accordingly, we had to update the xblock to the latest version which inculded that fix and still supported koa (`2.10.1`). However, openedx/xblock-lti-consumer#150 was not merged until tag `3.0.3`. Thefore, we created a custom tag, `2.10.1-opencraft` which includes the backported change on top of tag `2.10.1`
The previous lti-consumer-xblock commit hash was pointing to a code drift branch which was backporting openedx/xblock-lti-consumer#150 to tag `2.4.0` Unfortunately, `config_id` duplicate errors started showing for one of the clients. Accordingly, we had to update the xblock to the latest version which inculded that fix and still supported koa (`2.10.1`). However, openedx/xblock-lti-consumer#150 was not merged until tag `3.0.3`. Thefore, we created a custom tag, `2.10.1-opencraft` which includes the backported change on top of tag `2.10.1`
The previous lti-consumer-xblock commit hash was pointing to a code drift branch which was backporting openedx/xblock-lti-consumer#150 to tag `2.4.0` Unfortunately, `config_id` duplicate errors started showing for one of the clients. Accordingly, we had to update the xblock to the latest version which inculded that fix and still supported koa (`2.10.1`). However, openedx/xblock-lti-consumer#150 was not merged until tag `3.0.3`. Thefore, we created a custom tag, `2.10.1-opencraft` which includes the backported change on top of tag `2.10.1` (cherry picked from commit 85884f3)
This PR updates the lti-consumer-xblock version to a new commit that contains the backported fix from openedx/xblock-lti-consumer#150 (cherry picked from commit 9612bad)
The previous lti-consumer-xblock commit hash was pointing to a code drift branch which was backporting openedx/xblock-lti-consumer#150 to tag `2.4.0` Unfortunately, `config_id` duplicate errors started showing for one of the clients. Accordingly, we had to update the xblock to the latest version which inculded that fix and still supported koa (`2.10.1`). However, openedx/xblock-lti-consumer#150 was not merged until tag `3.0.3`. Thefore, we created a custom tag, `2.10.1-opencraft` which includes the backported change on top of tag `2.10.1` (cherry picked from commit 85884f3)
Somewhere between versions 2.0.0 and 2.1.0, the code to handle external parameter processors was dropped. This PR adds it back. Without this, external processors that are specified in the parameter processors settings is not called.
Jira Tickets: OSPR-5686
Sandbox URL: TBD
Testing Instructions:
Reviewers