This commit upgrades the version of the lti-consumer-xblock library from version 6.1.0 to version 6.4.0. Version 6.3.0 includes support for the Proctoring Assessment Messages of the 1EdTech Proctoring Services Specification (i.e. the in-browser proctoring launch). Version 6.4.0 includes changes to the user_id attribute in the LTI launch message of the LTI 1.1 XBlock launch.
Please see the CHANGELOG entry for these versions for a full description of the changes: https://github.com/openedx/xblock-lti-consumer/blob/master/CHANGELOG.rst#630---2022-11-16 and https://github.com/openedx/xblock-lti-consumer/blob/master/CHANGELOG.rst#640---2022-11-18. The commit messages are included below for convenience.
6.3.0
feat: adds support for LTI 1.3 Proctoring Service specification in-browser proctoring launch.
* Adds an Lti1p3ProctoringLaunchData data class. It should be included as an attribute of the Lti1p3LaunchData
data class to provide necessary proctoring data for a proctoring launch.
* Adds an LtiProctoringConsumer class. This class is used to generate LTI proctoring launch requests and to decode
and validate the JWT send back by the Tool with the LtiStartAssessment message.
* Adds an lti_1p3_proctoring_enabled BooleanField to the LtiConfiguration model. This field controls whether
proctoring is enabled for a particular LTI integration.
* Modifies the launch_gate_endpoint to support LtiStartProctoring and LtiEndAssessment LTI launch messages.
* Adds an start_proctoring_assessment_endpoint to support LtiStartAssessment messages from the Tool.
* Adds an LTI_1P3_PROCTORING_ASSESSMENT_STARTED signal. This signal is emitted when the LtiStartAssessment message is
sent from the Tool to inform users of the library that the LtiStartAssessment message has been received.
6.4.0
feat: add course flag to send external_user_id as user_id in LTI 1.1 XBlock launches
This commit introduces a new CourseWaffleFlag lti_consumer.enable_external_user_id_1p1_launches. When this flag is enabled for a course, LTI 1.1 XBlock launches in that course will send the user's external_user_id as the user_id attribute of the launch. external_user_id is the user's external user ID as defined, created, and stored by the external_user_ids Djangoapp in the edx-platform. When this waffle is not enabled for a course - the default case - LTI 1.1 XBlock launches in that course will continue to send the user's anonymous_user_id as the user_id attribute of the launch, as before.
This provides an opt-in opportunity for courses to send a consistent, static, and opaque user identifier in an LTI 1.1 XBlock launch. This may be necessary for integration with LTI tools that require such an identifier.
Please be aware that toggling this flag in a running course carries the risk of breaking the LTI integrations in the course. This flag should also only be enabled for new courses in which no LTI attempts have been made.
When running in a sharded MongoDB setup it's possible that querying the
modulestore right after the course publish signal will not return the
latest data.
This commit adds a delay similar to the one used in other places in the
codebase for a similar reason.
This function is no longer needed as all XModules have been converted to XBlocks.
XBLOCK_SELECT_FUNCTION Django setting is removed too, as it could take only `prefer_xmodules` or `default_select` values.
* fix: add missing permission/auth classes to init
* fix: add missing permission class
Django was complaining about adding JWT auth without the
NotJwtRestrictedApplication class which it would add automatically. Add
the class to remove that warning.
* style: use black / isort to fix import ordering
When a student submits a problem answer, the state is stored in a
StudentModule record containing answer, score, correctness, etc. The
record, though, is updated in multiple steps within the single request
(first the grade is updated, then the state is updated separately).
Each partial save would trigger a separate StudentModuleHistory record
to be stored resulting in duplicate and inaccurate historical records.
This solution uses the RequestCache to track within a request thread
which StudentModules are updated and a single corresponding
StudentModuleHistory id. If multiple update actions occur within the
request cycle, then modify the history record that was already
generated to ensure that each submission only results in one
StudentModuleHistory record.
This issue and its solution were discussed in:
https://discuss.openedx.org/t/extra-history-record-stored-on-each-problem-submission/8081
Clearing the RequestCache was intended to address memory leaks in the
celery workers. Celery worker processes will process many tasks before
they are terminated. RequestCache cleanup typically happens in the
RequestCacheMiddleware class, and middleware never executes for celery.
To get around that issue, the CLEAR_REQUEST_CACHE_ON_TASK_COMPLETION
setting was created to clear the RequestCache after every task was
successfully completed.
This works fine when celery is running as a separate process, as it's
set up to do in production. But during development, the
CELERY_ALWAYS_EAGER setting variable is set to True, meaning that
celery tasks are run in the same thread as the Django Request. This is
meant to make debugging easier, as task failures run as part of the
request cycle and will raise exceptions that are visible to the
browser.
However, celery tasks are triggered from many different actions. That
means that the RequestCache was being cleared many times during the
course of processing a request. This led to behavior that was
potentially slower, but also incorrect–the RequestCache was getting
flushed in a way that wouldn't happen in any deployed environment
because celery would be running in separate processes there. This came
up when trying to fix an issue around extra history records being
created during problem submissions:
https://discuss.openedx.org/t/extra-history-record-stored-on-each-problem-submission/8081
Furthermore, it's not necessary to prevent RequestCache memory leaks
when running in CELERY_AWLAYS_EAGER mode in development because the
middleware cleanup happens automatically–as everything is running as
part of the request/response cycle.
There are times in which we may want to run celery eagerly and still
clear the cache, such as testing. I have set
CLEAR_REQUEST_CACHE_ON_TASK_COMPLETION = False in all dev and test
environments that already have CELERY_ALWAYS_EAGER = True. The unit
test that specifically tests whether the request cache is getting
cleared upon completion of a celery task then overrides
CLEAR_REQUEST_CACHE_ON_TASK_COMPLETION = True even though
CELERY_ALWAYS_EAGER = True for the sake of that specific testing
purpose.
6.0.0 refactored this xblock in a way that does not work with studio
leaving blocks partialy broken. While that is being fixed, roll back
to 5.0.1.
Bug ticket: MST-1697
The teams stopped working when we moved the repo to the openedx org.
Also, things have been re-organized at 2U so it's unclear if these
ownership mappings are still relevant. I'm removing them for now and
I've posted on the forums to let people know if they want to add back in
more relevant teams.
Relevant Link: https://discuss.openedx.org/t/edx-platform-codeowners/8649
