Hi, We want to integrate coding question evaluation into our LMS. We already have an in-house built coding question evaluation engine on our platform and we want to use it as a LTI tool with open edx. We want the question creation and question evaluation to happen on our platform, whereas we should be able to send back the grades of the question evaluation back to the LMS(which I guess is possible with LTI). But we would want to link the question creation part to happen on our platform and not on open edx. We want open edx to redirect to our platform’s question creation/updation page whenever the organizer would want to create or edit the question. We would also want the organizer to avoid the overhead of maintaining the LTI configs for each and every question and let the platform itself take care of those. So we were looking for sthg like LTI in an xblock kind of solution.
What we want:
Redirection to our platform’s question creation page when a new codin question component is created. And whenever the organizer wants to edit that component he should be redirected to our platform’s page.
When learner attempts the question he should be redirected to our platform’s question evaluation page where he would solve the problem and the results of his submission would be posted back to Open edx’s LMS (I guess this is already possible)
What we have planned to do:
Create a generic question xblock that will redirect to our platform for question creation and updation.
Maintain LTI configurations and other settings by the xblock itself (if possible).
Use our own backends to post the submission results back to the LTI component of this block so that the learner can see his grades in the LMS itself.
We would probably want to avoid creating xblocks for each and every question because of the following reasons.
We already have well documented internal apis that do this for us and we dont want to duplicate that in an xblock.
In the future we would want to integrate other types of question evaluations that happens on our platform like ai-challenge evaluation and so on.
If you already had the questions created in a huge problem bank on your system, then I would say that LTI sounds like the way to go, and can pretty much do everything that you want.
But it sounds like the questions aren’t authored in advance, so what you want is for your course authors that are using Studio to be able to create coding questions using your platform while they are authoring the course in Studio. In that case, I don’t think LTI really provides the right mechanisms for displaying an external authoring tool to authors; it only provides an external learning tool to learners as far as I know.
It’s also unclear to me whether you are referring to redirecting to your platform or embedding your platform. If you just mean embedding (as in an iframe), then LTI works great; but if you really literally mean “redirecting” where the Open edX platform disappears and the browser is fully redirected to your external platform, which will lately fully redirect back to Open edX, then I don’t think LTI can handle that either - it is focused on the iframe embedding use case.
Based on my tentative understanding of what you want, I think a custom XBlock would be the right approach. You can keep it very simple and the “Author view” of the XBlock can just be either an iframe that embeds your external platform’s authoring tools or a “launch” button that opens the editor in a new tab/window or redirects to the platform and passes enough state information for the platform to be able to redirect back to Open edX when the editor is done. Likewise, the “student view” of the XBlock can just be an iframe or a launch button that takes the student to your platform. And you can implement a “noauth XBlock JSON handler” which is essentially like a web hook that your external platform can POST a grade to (or any other information), which the XBlock will then submit to the LMS.
So if I am getting it right if we implement a custom xblock that takes care of the webhook then we might not need any LTI. And this same xblock could handle the redirections to our platform on the admin side as well. Please correct me if I am wrong.
Thank you @braden for your support. Can you please point any resources or documentation which describes “noauth_json_handler” of xblocks. We are new to open edx and we are not able to find it. Thanks.
Option 1 - plain XBlock: On second thought, if you can use the user’s own browser to POST the data back to the XBlock handler, it’s even better and you can just use a regular XBlock handler (JSON handler).
Option 2 - noauth XBlock: However, if you need to have your external backend POST data directly to the LMS (i.e. to a REST webhook), not using the user’s browser, that approach won’t work as there are no authentication cookies set on the backend to identify the user. So instead you need to POST to a “noauth” handler which allows unauthenticated requests, and you’ll have to specify the user ID within the payload (and some sort of authentication). To create a noauth handler, you specify thirdparty=true when calling self.runtime.handler_url(...), and that will return a full noauth URL that can be used without authentication. There is another function called rebind_noauth_module_to_user that can be used once you know which user it is, and once you’ve “rebound” to the user you can issue grades for the user.
Option 3 - hybrid: That said, the noauth stuff is a fairly obscure part of the platform and may not be the most robust approach. If you can’t go with Option 1 (having the user’s own browser POST data to an XBlock handler), yet another option is to actually use LTI, because LTI already implements the authenticated webhooks to post grades back to the platform from the external tool. But the trick is you can create your own subclass of the LTI XBlock which uses LTI for the student_view (and which takes care of most of the LTI configuration for authors), and which also supports displaying your custom editor for the author_view. The regular LTI xblock can’t do that but if you subclass it, you can build out the best of both worlds.
Oh thank you @braden . Option 3 seems like a tempting option to go with. Are there any resources or documentation that describes to go about doing this. I mean changing the behaviour of the default lti_xblock with our own xblock?
There’s no documentation that I know of about subclassing an existing XBlock, but it works the same way as subclassing and modifying any other python project. The source code is at GitHub - openedx/xblock-lti-consumer - you can create a copy of it, change the name of the python module, and change the entry point name in setup.py, then install it and it should already be working, and you just start iteratively modifying it until it works how you want it to.
