LTI improvements [for Verawood]
The direction for Verawood is to make authoring fast and make LTI configurations reusable. Following tasks have been planned for Verawood.
1. LTI Consumer XBlock UI refactor
As of Ulmo, the LTI Consumer XBlock configuration is a single long form that mixes protocol/security settings with services, grading, and launch UX. Required vs optional inputs aren’t clearly distinguished, and the heavy on-screen help text makes the modal feel cluttered and intimidating especially for first-time setup.
We intend to make the XBlock configuration process less intimidating more legible.
For details and mockups, see LTI Consumer XBlock - Proposed UI/UX
2. Make LTI consumer XBlock reusable
As described here, copy/paste or duplicating the XBlock does NOT work for LTI 1.3.
We intend to make updates on the BE such that pasting or duplicating the XBlock will also copy the client_id, deployment_id, Keyset URL and Access Token URL of the source XBlock.
Editing the pasted/duplicated XBlock won’t create new credentials unless user tries to change Tool Public Key/Keset URL.
3. Launch URL override for LTI store
For instances that enable the LTI store plugin, we will show the Launch URL override option by default. At present, it is behind a waffle flag named lti_consumer.enable_external_multiple_launch_urls which is default. We intend to remove the waffle flag.
Comments
Rômulo Penido Jenna Makowski thank you for the feedback.
I agree that:
It’s risky to let all course authors create/edit reusable LTI configs from inside the XBlock
It’s probably not realistic for Verawood given we have ~3 months and the current FE SOW is mainly about reorganizing XBlock fields into tabs” (also the editor isn’t Paragon/React, so new UI will take time).
My new proposal is as follows.
For Verawood:
Make ltistore the default path in the LTI XBlock UI (pick existing reusable config first). Still allow inline config, but show a warning that ltistore isn’t used.
Refactor XBlock UI into tabs as Marco Morales proposed here. Marco we need to add the reusable config selection field.
[Budget-conditional] Add placement-level overrides when using a reusable config (e.g., per-assessment Launch URL for Codio + other placement-variable fields; not credentials/endpoints).
Fix the deployment_id override issue.
For Willow and beyond:
Build Studio UI to manage reusable configs (validation, usage counts, “test launch”, safer editing flows etc.).
Use RBAC to define/manage permissions for reusable configs in the UI proposed above.
Move LTI store code from plugin into core IF NEEDED.
Evaluate ROI/feasibility of adding config scopes (course/org/site) and map them to RBAC.
Evaluate ROI/feasibility of bulk importing/syncing configs from external systems.
Evaluate ROI/feasibility of building dynamic registration.
If this direction makes sense, i think the next step is for Marco Morales to finalize the mockups.
Rômulo Penido Braden MacDonald Marco Morales Jenna Makowski looking forward to your feedback on this proposal.
I think this makes sense. The scope for Willow may be a bit large, but we can refine over the coming weeks as needed. I would definitely prioritize #1 Studio UI and #2 RBAC permissions.
Another scope I want to include for Willow is an MVP for using Open edX as an LTI Provider. We can discuss more.
Thank you for consolidating everything aamir ayub!
Just to make sure I’m getting it right: the tabs will be “General” (?), “Grading”, “Advanced Information Sharing” and “Appearence Options”? The first one (where we have the Display Name field) doesn’t have a title, so I will use “General” and we can update it if necessary.
Rômulo Penido Marco has requested a review from engineering on mockups that his team have drafted here. I’d like you to take a look at the general approach outlined in the section named “Verawood LTI Authoring workflow”. I’ve tried to explain it in this TEMP doc: LTI Consumer XBlock - Proposed UI/UX.
But please continue to use this comment section or the figma file for questions or comments, instead of LTI Consumer XBlock - Proposed UI/UX.
Marco and I will wait for you to raise any major red flags. If you don’t see any, Marco and his team will work on developing detailed mockups.
cc: Marco Morales
Hi aamir ayub! CC Marco Morales
In its current state, when the user clicks Create or Paste, we create the XBlock in the unit/library, without any other user input or interaction, using default/blanks/copied values. Changing that would take considerable effort (both in the frontend and the xblock api), and we would need a discovery to evaluate it. So, I don’t think this is viable for Verawood.
After that, the user can Edit the XBlock (whether it was recently created or already configured), and we show the Edit modal. This is the same for all XBlocks and, in the current state, we only change the modal content for any specific XBlock. It is not possible to show the Interstitial modal.
We can show it as part of the “Stepper” from ‘2.1 Setup'. One issue is that we don’t have a reliable way to differentiate a new and a configured XBlock. So, having the same interface that can handle both cases would be ideal.
I worked with the code a bit and I think it is possible to implement a simple stepper like shown in the Figma. Something near we have with the Drag and Drop XBlock, but with a visual steps on top for information or navigation.
The selection buttons look great. I will try to implement them, but, for now, we only have Combo boxes.
We can overcome all these limitations in the future, but it is important to note that we may also need to modify the XBlock API (not only the frontend) to accommodate these improvements.
when the user clicks Create or Paste, we create the XBlock in the unit/library, without any other user input or interaction, using default/blanks/copied values
Rômulo Penido thank you for the review and for pointing this out.
Marco Morales i’m ok with skipping the interstitial for Verawood and asking user to manually enter the LTI Reusable Configuration ID, as is the case in the current workflow.
We can revisit interstitial for Willow when we and the dev team will have more time/budget to plan the necessary FE and BE changes.
Rômulo Penido is it possible to show user a list of existing reusable configuration IDs without causing a major scope change? It’ll essentially do what the insterstitial is supposed to do but without a major FE change.
is it possible to show user a list of existing reusable configuration IDs without causing a major scope change? It’ll essentially do what the insterstitial is supposed to do but without a major FE change.
aamir ayub I think we can do it. If it turns out to be a problem during implementation, I will let you know.
In its current state, when the user clicks Create or Paste, we create the XBlock in the unit/library, without any other user input or interaction, using default/blanks/copied values. Changing that would take considerable effort (both in the frontend and the xblock api), and we would need a discovery to evaluate it. So, I don’t think this is viable for Verawood.
– Today we take educators right int othe text editor + problem editor, is the reason this isn’t an option for Verawood because a react based editor is not in scope for Verawood?
I ask this up front because most of the visual patterns proposed in the mocks rely on paragon / benefit from paragon. If there’s another technical reason why the block has to be added behind the scenes that isn’t the react/ non-react reason let me know.
It shouldn’t be a major workflow shift to update the mocks to create the block and require an educator to hit edit, but I wanted to check in on the react point - Rômulo Penido / aamir ayub
Hi Marco Morales!
– Today we take educators right int othe text editor + problem editor, is the reason this isn’t an option for Verawood because a react based editor is not in scope for Verawood?
I didn’t check it thoroughly right now, but opening the LTI editor after creating the XBlock should be possible.
If you click Cancel after adding a Text/Problem, you are only skipping the edit. The block is already in place. What I meant is that (in the current state) we can’t show a dialog before the creation of an XBlock. I.e., adding a one-time modal when we paste a LTI Block, asking if we want to reuse the config or copy it, wouldn’t be possible. This applies to all blocks and is not related to Paragon. Sorry if I wasn’t clear before!
The issue with the editors that don’t use Paragon is only that we need to implement the components from scratch: the html, css and javascript, and this is more time-consuming than using the default HTML components.
adding a one-time modal when we paste a LTI Block, asking if we want to reuse the config or copy it, wouldn’t be possible. This applies to all blocks and is not related to Paragon.
I am in favor of skipping the selection interstitial (1st screenshot below) in Verawood. Marco Morales This would mean we’ll need a manual entry and selection field in the Setup tab similar to what we have now (2nd screenshot below).
Rômulo Penido i have a question about “Add placement-level overrides when using a reusable config”:
Reusable configuration has its own client_id and deployment_id (both user provided) and Keyset URL and Access Token URL (auto-generated).
If we were to edit a reusable config in XBlock and then save, will the XBlock be saved with client_id, deployment_id, Keyset URL and Access Token URL from the reusable field? Or will it create its own? If it creates its own, this may break the integration.
i have a question about “Add placement-level overrides when using a reusable config”:
Reusable configuration has its ownclient_idanddeployment_id(both user provided) andKeyset URLandAccess Token URL(auto-generated).
If we were to edit a reusable config in XBlock and then save, will the XBlock be saved withclient_id,deployment_id,Keyset URLandAccess Token URLfrom the reusable field? Or will it create its own? If it creates its own, this may break the integration.
I think Navin Karkera would be in a better place to respond this one!
aamir ayub Currently, xblock fields are mostly ignored if configuration type is set to Reusable.
No placement-level overrides (today): when an XBlock references a reusable configuration, authors can’t override fields like Launch URL.
Actually, there is an option to override launch url per xblock even if you select reusable config. We just need to enable lti_consumer.enable_external_multiple_launch_urls waffle flag and then the block launch url will be given priority over reusable field.
Navin Karkera thank you. I’ve tested it in Ulmo and it works. Here are my suggestions:
We only need Launch URL override for now, which already exists. I recommend removing the waffle flag or at least keeping it ON by default.
Marco Morales i recommend that we show all LTI fields in case user selects reusable config. However, only the Launch URL will be editable.
cc: Rômulo Penido
Regarding this point:
adding a one-time modal when we paste a LTI Block, asking if we want to reuse the config or copy it, wouldn’t be possible.
What we are suggesting is that this is actually a part of the LTI consumer editor itself, essentially meaning that hwether you configure an LTI block at the single block / component level, or whether you are adding a block eventually at the course level or higher, that you have an initial step of choosing an existing “reusabable” configuration or starting from a new one.
We are working on mockups that visually incorporate this first step into the editor step sequence for review. We would advise for this over the current plugin experience which simply sets / adds a field to the xblock for “reusable configuration” vs “new configuration.” Regardless of what is done in the backend, if that is how the plugin is set up to be a field level value that isfine, but for educators the workflow requires that you decide first if you are using an existing configuration (and if so which one) or using a new one.
This allows for us to (in the future) as other configuration options exist (creating it at thecourse level or org / site etc in future named releases) the same workflow would exist (broadly speaking): add new block or add block from existing configuration.
We are still working on full detailed updates to this shift since the last wireframes you reviewed, but this is in essence the first step when you add an LTI block from the secondary menu within the Advanced menu on the unit page:
Educators are either selecting a “reusable” configuration from LTIStore or adding a new one. This flow (if included in Verawood) would need (as I understand it) for the LTIStore / Plugin to have a course key scope, so it only shows available configurations bound to this specific course. Whenever you create a new one and hit save not only would the bloc klevel configuration be created but a “reusable” LTIStore course level configuration would be added so the next time you come into this flow you’d have the ability to skip some steps by selecting H5p / Coderoom (in the visual example above).
In the event that we cannot take advantage of reusing configuration on the second time through adding a block within a course, this first step cannot exist, and then the question becomes, what happens to the setup tab (shown below).
In the setup tab, you are setting the “LTI ID” which echoes the idea of the name / ID used today in LTI passports, and is the name you’d see in Step 0 (the one I shared visually above) the second time you are adding an LTI block to your course.
In the event that we aren’t using the LTIStore plugin, you’d be setting up the LTI ID value each time, or perhaps allowing for that input text field to let you see (via type ahead or something else) existing lti passport configurations / LTI ID that exist. Presumably you’d need to ensure uniqueness as is the case today with course level lti passports. Incorporating this into the block editing experience would eliminate the need to have the advanced setting workflow.
It seems that not matter what, if a goal is to streamline the process with the specific aim of removing the advanced settings workflow / confusion, we alreayd have to validate / check against existing LTI IDs within a course, but that seems (perhaps naively) similar to the LTIStore table / plugin’s sense of a reusable configuration.
Let me know if this helps. We should have updated full detailed wires to shar esoon but I wanted to at least send this thread / question set along async in case it spurred other thoughts or feedback. FYI Rômulo Penido , aamir ayub , Phu Nguyen
Hi Marco Morales! We are planning to make the LTIStore part of the core, so we can assume it will always be present (this means we will have a “Reusable” option available).
Educators are either selecting a “reusable” configuration from LTIStore or adding a new one. This flow (if included in Verawood) would need (as I understand it) for the LTIStore / Plugin to have a course key scope, so it only shows available configurations bound to this specific course. Whenever you create a new one and hit save not only would the bloc klevel configuration be created but a “reusable” LTIStore course level configuration would be added so the next time you come into this flow you’d have the ability to skip some steps by selecting H5p / Coderoom (in the visual example above).
I don’t think it would be easy to add a course-key scope to the reusable configuration (at least for Verawood). It would break copy/paste from different courses, and I’m not sure how we handle it for libraries. So I’m not sure we could easily create new configurations without using the Djando Admin UI for Verawood.
In the event that we aren’t using the LTIStore plugin, you’d be setting up the LTI ID value each time, or perhaps allowing for that input text field to let you see (via type ahead or something else) existing lti passport configurations / LTI ID that exist. Presumably you’d need to ensure uniqueness as is the case today with course level lti passports. Incorporating this into the block editing experience would eliminate the need to have the advanced setting workflow.
Because of the limitation above, even with LTIStore, we need a way to put the configurations directly on the block, as we do today, so a Course Author can configure the block without admin access.
Does that make sense?
CC Feanil Patel Navin Karkera
I’m trying to find where the decision to make LTIStore part of the default build came from, can someone point me to the relevant discussion? Is this needed to make copy-paste work correctly right now?
What I was hoping to avoid is to avoid a workflow where you’d need to copy in something from django admin to be able to request an “existing” configuration in the authoring workflow. Similarly hoping to avoid a field / dropdown that is called “reusable” sicne the new stepper flow doesnt work. for this.
In the new stepper flow the “LTI ID” field which is the first item you see / can set (if there is no selection of existing configuration step) would be to type in a name / ID. That would be where we’d want to let someone select an “existing” or “reusable” configuration and that would set / hide other fields like key / secret that are already set potentially.
What is the key / name / way to do the following you mentioned previously - is that an LTI ID / text string? somethign else?
Because of the limitation above, even with LTIStore, we need a way to put the configurations directly on the block, as we do today, so a Course Author can configure the block without admin access.
--
Separate Question
For the LTIStore work, if there is no course context today, and it sounds like that’s not realistic for Verawood. Today, is the plugin used by anyone for course specific blocks? If you set up a block called h5p with specific credentials it soudns like that woudl be an instance wide configuration? IF another course had separate h5p credentials would they need to use a different unique name? how does that work today in the plugin.
I’m trying to find where the decision to make LTIStore part of the default build came from, can someone point me to the relevant discussion? Is this needed to make copy-paste work correctly right now?
Feanil Patel LTIStore stores lti configuration separately, not tied to any xblock and since any block can point to this configuration and reuse it, it works perfectly with copy-paste and import-export. The only limitation currently is that the configuration is not imported to a different instance when you export a course and import it in a separate instance.
If you set up a block called h5p with specific credentials it soudns like that woudl be an instance wide configuration? IF another course had separate h5p credentials would they need to use a different unique name? how does that work today in the plugin.
Marco Morales Yes, the config is instance wide.
In the above screenshot, you can see that the config is instance wide and the Filter Key can be used in any LTI xblock in any course in the instance.
What I was hoping to avoid is to avoid a workflow where you’d need to copy in something from django admin to be able to request an “existing” configuration in the authoring workflow. Similarly hoping to avoid a field / dropdown that is called “reusable” sicne the new stepper flow doesnt work.
I agree, currently the author will need to copy the Filter Key and paste it in the Reusable field in LTI xblock.
I like to idea of being able to select existing reusable configurations from a dropdown or similar component instead of copy-paste.
For editing the reusable configuration, we need two things:
Copy the reusable configuration and link it to a course.
Edit it via studio interface in a separate page instead of editing it directly in the xblock.
I' quoting
Rômulo Penido from this slack thread.