32d48e7881
This commit upgrades the version of the lti-consumer-xblock library from version 6.4.0 to version 7.0.2. This includes versions 7.0.0, 7.0.1, and 7.0.2. Version 7.0.0 includes refactoring to remove deprecated method calls to rebind_noauth_module_to_user, get_real_user, runtime.hostname, and runtime.course_id. Version 7.0.1 includes a fix to the clean method of the LtiConfiguration model. The fix changes the way we look up the course ID so that we can access the course ID without needing to load the XBlock. Version 7.0.2 includes fixes to LTI 1.1 Basic Outcomes Services and LTI 2.0 Result Service when using an external_user_id as a user identifier. Note that version 7.0.1 was originally deployed in https://github.com/openedx/edx-platform/pull/31369. It was reverted soon after in https://github.com/openedx/edx-platform/pull/31377. The issue occurred in version 7.0.0, in the following line https://github.com/openedx/xblock-lti-consumer/pull/249/files#diff-ab027143adc95b9776c12e973e28f025a21b0d88112937af93645829686527fdL186. self in the call to the service is an instance of the OutcomeService. self should be an instance of an XBlock (i.e. LtiConsumerXBlock). Version 7.0.2 fixes this bug by moving the call to the service to the LtiConsumerXBlock, where self is an instance of an XBlock. Therefore, we are deploying this version to fix forward. Please see the CHANGELOG entries below for these versions for a full description of the changes. Version 7.0.0: https://github.com/openedx/xblock-lti-consumer/blob/master/CHANGELOG.rst#700---2022-11-29 Version 7.0.1: https://github.com/openedx/xblock-lti-consumer/blob/master/CHANGELOG.rst#701---2022-11-29 Version 7.0.2: https://github.com/openedx/xblock-lti-consumer/blob/master/CHANGELOG.rst#702---2022-11-29. The commit messages of each version are included below for convenience. 7.0.0 ----- refactor: replace block.location with block.scope_ids.usage_id 7.0.1 ----- fix: do not attempt to load the block just to look at the location the block is not loadable in exams so clean fails in that IDA, but we shouldn't need the block to ask a question about the course 7.0.2 ----- In #307, we added the ability to send a stable, static user identifier (i.e. external user ID) to fix failed launches with the QwikLabs tool. This is because the QwikLabs tool did not work with the course-anonymized user IDs we used to send (i.e. anonymous user IDs). Inadvertently, this change broke the LTI 1.1 Basic Outcomes Service and the LTI 2.0 Result Service for courses that use the external user ID (i.e. they have the lti_consumer.enable_external_user_id_1p1_launches CourseWaffleFlag enabled). The Basic Outcomes Service and Result Service handle grade pass backs. Because we now have two ways to identify a user in LTI 1.1/2.0, we must update the Basic Outcomes Service and Result Service to support both. This commit fixes this bug.
Requirements/dependencies
=========================
These directories specify the Python (and system) dependencies for the LMS and Studio.
- ``edx`` contains the normal Python requirements files
- ``edx-sandbox`` contains the requirements files for Codejail
- ``constraints.txt`` is shared between the two
(In a normal `OEP-18`_-compliant repository, the ``*.in`` and ``*.txt`` files would be
directly in the requirements directory.)
.. _OEP-18: https://github.com/openedx/open-edx-proposals/blob/master/oeps/oep-0018-bp-python-dependencies.rst
Upgrading/downgrading just one dependency
-----------------------------------------
Want to upgrade just *one* dependency without pulling in other upgrades? Here's how:
1. Change your dependency to a minimum-version constraint, e.g. ``my-dep>=1.2.3`` (or update the constraint if it already exists)
2. Run ``make compile-requirements`` to recompute dependencies with this new constraint
If you instead need to surgically *downgrade* a dependency, perhaps in order to revert a change which broke things:
1. Add an exact-match or max-version constraint to ``constraints.txt`` with a comment explaining why (and ideally a ticket or issue link)
2. Lower the minimum-version constraint, if it exists
- Not sure if there is one? Try going on to the next step and seeing if it complains!
3. Run ``make compile-requirements``
This is considerably safer than trying to manually edit the ``*.txt`` files, which can easily result in incompatible dependency versions.