This commit updates the version of the lti-consumer-xblock from 4.3.0 to 4.3.1. This installs the newest version of the lti-consumer-xblock library. This version includes the following changes.
This commit fixes three bugs.
1. The first bug is that the lti_version field is inappropriately hidden in the Studio author view edit menu when the selected config_type is database.
2. The second bug is that the editable_fields property of the LtiConsumerXBlock is inappropriately excluding LTI 1.3 fields when the config_type is database. The editable_fields property should include LTI 1.3 fields even when the config_type is database, because the Javascript defined in xblock_studio_view.js may want to show these fields if the user selects a different config_type in the menu. We want to support a dynamic edit menu, so these fields must be considered editable by the XBlock in order for the Javascript to be able to manipulate them.
3. The third bug is in inconsistent rendering of the Studio author view edit menu. Depending on the order in which a user selects lti_version, config_type, or lti_1p3_tool_key_mode, different sets of fields are displayed, due to the overlapping sets of rules that govern what fields should be hidden or shown for a given field selection. This commit corrects this inconsistent rendering by first showing all fields and then gradually hiding fields depending on the sets of rules, for each change to the fields.
The decision to provide Restricted Applications expired
JWTs was superseded by another ADR. This commit simply
adds clarity around that change.
Co-authored-by: Phillip Shiu <pshiu@users.noreply.github.com>
This setting allows loading of Resource Templates from outside the
edx-platform codebase.
Operators will be able to add their own custom resource templates
without needing to fork the codebase.
This commit updates the version of the lti-consumer-xblock from 4.2.2/4.2.1 to 4.3.0. This installs the newest version of the lti-consumer-xblock library. This version includes the following changes.
This version adds additional core LTI 1.3 and LTI Advantage variables to the LtiConfiguration model. The additional core LTI 1.3 variables are lti_1p3_oidc_url, lti_1p3_launch_url, lti_1p3_tool_public_key, and lti_1p3_tool_keyset_url. The additional LTI Advantage variables are lti_advantage_enable_nrps, lti_advantage_deep_linking_enabled, lti_advantage_deep_linking_launch_url, and lti_advantage_ags_mode.
This commit also adds a configuration type to the LtiConsumerXBlock to support the storage of these Lti variables on the LTIConfiguration model (i.e. the database) instead of the XBlock itself.
Changes that allow the use of this configuration option are behind the lti_consumer.enable_database_config CourseWaffleFlag.
As part of dissolving our sub-projects in edx-platform, we are moving this package under the xmodule directory.
We have fixed all the occurences of import of this package and also fixed all documents related references.
This might break your platform if you have any reference of `import capa` or `from capa import` in your codebase or in any Xblock.
Ref: https://openedx.atlassian.net/browse/BOM-2582
This file was originally checked into
edx-platform so that other developers
could import it into Postman (https://postman.com)
in order to easily query the ORA staff grader API.
Unfortunately, it is very large (1.3 MB). This:
* slows down edx-platform shallow cloning,
* increases the minimum edx-platform image size,
* adds noise when text-searching the repo, and
* sets a precedent for other developers to
check similar files into this repo.
This cost is not justifiable
for a closed-source 3rd-party developer tool.
In order to gain more information about ongoing questions related to the potentially out-of-sync nature of the SQL and MongoDb tables in Split Modulestore, I have created the management command to list all courses with out-of-sync active_versions and course_index entires.
This should have no direct impact on anyone, nor alter anything.
part of an on-going investigation to figure out 500 errors in studio.
For staff grader setup, we want to know the response type to do better
rendering of the response. This derives from ORA's text_response_editor
setting and is either "text" (default) or "tinymce".
Co-authored-by: nsprenkle <nsprenkle@2u.com>
