Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
feat: LTI 1.3 reusable configuration #390
feat: LTI 1.3 reusable configuration #390
Changes from 1 commit
a28dcc1
681abaf
1a9ca9a
3c20fab
f15a78c
0af3753
c8031eb
8087346
c9a2521
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Something odd happens when I try to use the external configuration directly from the XBlock. When I set the
Configuration Type
toReusable Configuration
and provide a validLTI Reusable Configuration ID
, the XBlock break withError: (1048, "Column 'version' cannot be null")
. The relevant part of the traceback is: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.
This is because the external ID set on the XBlock is not found, this is either because the reusable configuration feature is not properly setup or the external configuration doesn't exist. If you check this specific line you can notice that if no config is found the "version" value will return None, once this value is sent to the
_get_or_create_local_lti_config
function, when it tries to save the new values to theLtiConfiguration
it fails since "version" value cannot be null. This could be fixed by adding an extra validation to any required field from the external config on_get_lti_config_for_block
but I think it's out of the scope of this PR, an issue about this should be created.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.
Created #420.
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.
Why do we introduce the XBlock configuration as a fallback? What about the value stored in the DB (
self.lti_1p3_oidc_url
)?Having a fallback is helpful, but this behavior should be clearly documented.
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.
We introduce it so course authors can override the OIDC URL, launch URL or deep linking launch URL, without the need to create a new configuration. We could add also the DB values as a fallback, I didn't wanted to introduce to much options on this fallback but also having the fallback on the DB might be useful. What do you suggest this be documented on?, I just thought about adding a code comment to describe this behavior but I agree it might be better to have it documented.
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.
@kuipumu , ah, right, we use them as overrides, not fallbacks.
Should we also override other values (like
client_id
,rsa_key
) through theLtiConfiguration
? Quick context: I'm talking only about theLtiConfiguration or ExternalConfiguration
condition since these values cannot be easily modified (or are not stored) within the XBlock fields.I believe that the most discoverable solution would be adding this information directly to the help text of each XBlock/DB field that can be overridden this way. Something like "If the configuration is retrieved from an external store, this value overrides the one specified in the external configuration.", but with an indication that this is not applicable when you use the
CONFIG_ON_DB
option.@zacharis278, what do you think?
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 think an issue we run into with the override functionality is right now the configuration options are exclusive. You pick either xblock, database, or external. If you choose external it's ambiguous what the next most important configuration location would be. I'd agree making this not applicable to
CONFIG_ON_DB
is probably the simplest short term solution around that. That said, this would now differ from the 1.1 implementation. If we're going to add an override feature its behavior should be consistent across LTI versions.I'm leaning towards suggesting we break override behavior out into it's own PR and instead focus on parity with the existing 1.1 solution in here. Taking time to discuss/consider the full list of fields that are potentially overridable at the block level and how we visually communicate to course teams how it would work might hold up the core behavior of this PR.
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.
@zacharis278 I agree that we should make this PR only about making LTI 1.3 external configuration 1:1 with the LTI 1.1 implementation and move other specific features (multi-tenancy, field override) into separate PRs, I will create these PRs has soon as we merge this changes. I already removed anything related to field overrides and multi-tenancy from the PR.
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.
Is this change backward-compatible? Shouldn't we fill these fields in the migration?
Also, why are we adding these fields to this model? A single
LtiConfiguration
entity can have only one set ofoidc_url
,client_id
anddeployment_id
values. TheLtiAgsLineItem
entity can be identified by theresource_link_id
. If I understand this correctly, as long as the deployment ID is defined in the database configs (instead of being tied to, e.g., an organization or a DjangoSite
), this relation should not change.Using the single-tenant deployments was a deliberate architectural decision, so if we want to change it, it would be reasonable to write a new ADR for this. We should also prepare the documentation that explains how to configure it. We shouldn't add undocumented features.
It would be better to split this functionality into a separate PR.
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.
A single LtiConfiguration entity can only have one set of oidc_url, client_id, and deployment_id values set on the DB and XBlock, but once we use external configurations, the oidc_url, client_id and deployment_id values on the external configuration could change, this will mean that the gradebook won't change even if the oidc_url, client_id and deployment_id values changed for the LtiConfiguration. Since each lineitem should only expose gradebook information directly tied to the tool deployment, I modified the LtiAgsLineItem model to include the oidc_url, client_id and deployment_id so we are querying the LtiAgsLineItem on LtiAgsLineItemViewset not only by the lti_configuration but also by the values currently being used by the LtiConfiguration. I might be wrong about this, so please correct me if I'm wrong.
Also, you are correct, this fields should be filled in the migration, otherwise, this change wouldn't be backward compatible if applied.
We noticed the possibility of using deployment IDs while using an external configuration, I can separate anything related to implementing the use of multi-tenancy with external configurations on a separate PR to avoid increasing the complexity of the initial implementation of external configurations for LTI 1.3. What do you think if I add an ADR on how to set external configurations for LTI 1.3 and another ADR about external configurations multi-tenancy on this other PR I will open?.
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.
@kuipumu, yes, please move the multi-tenancy-related things to a separate PR. Once we merge the reusable LTI 1.3 configs, catching potential regressions will be much easier.
Sounds reasonable to me. Do we have a rough timeline for this separate PR? It would be good to add the LTI 1.3 external configurations ADR before the Quince release.
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.
@Agrendalath I removed anything related to multi-tenancy from this PR, I don't have a rough timeline for this PR, I would think that has soon has we end merging this feature I can create a PR for anything related to multi-tenancy and external configurations.
I will work on an ADR ASAP to include in this PR related to LTI 1.3 external configurations, the Quince release is expected to be released when?
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.
@kuipumu, Quince will be released in December.