We don't depend on it directly we just get it as a side-effect of
XBlock so make that more clear while we're updating the package to the
new name on PyPI
This commit upgrades the version of the lti-consumer-xblock library from version 7.2.2 to version 7.2.3. This new version contains a fix to the LTI PII sharing consent dialog.
Please see the CHANGELOG entry for this version for a full description of the fixes: https://github.com/openedx/xblock-lti-consumer/blob/master/CHANGELOG.rst#723---2023-01-24. The commit message is included below for convenience.
This commit fixes a bug in the PII sharing consent dialog.
The bug resulted in bizarre behavior when there were more than one LTI component in a unit. For example, if there were two LTI inline launches in a unit, two "OK" button would appear in a single component, instead of in their respective components. Another example is that clicking the "View resource in a [modal|new] window" buttons under two LTI components resulted in the "OK" and "Cancel" buttons as well as the PII sharing prompt appearing in a single component, instead of in their respective components.
This is because the dialog-container div that is dynamically created in the Javascript was not scoped to the LTI component, so there was a div with a id of "dialog-container" for each component configured to share PII. When dynamically inserting and removing buttons and the PII sharing prompt, the Javascript would simply find the first div with the dialog-container ID and operate on it, instead of the div appropriate to the component the user is interacting with.
This commit upgrades the version of the lti-consumer-xblock library from version 7.1.0 to version 7.2.0. Version 7.2.0 includes a number of fixes to bugs relating to personally identifiable information (PII) sharing in LTI launches in both LTI 1.1 and LTI 1.3. Version 7.2.0 also enables PII sharing (username and email) in LTI 1.3 launches.
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#720---2022-12-15.
We have a need to lock the version of Django for production and tests, but
also to test on newer versions of Django so that we can get the repo ready
for long-term-support releases.
We've been doing that by extracting the `django==x.y.z` from the
pip-compiled files and moving it to a django.txt that is then co-installed
but can be overridden during tests. The problem is that this can result
in broken packages.
The approach here is to have `make test-requirements` continue to
ensure a consistent set of packages, and then install a different
Django on top of that in the CI script -- and call `pip check` to make
sure that combination isn't broken.
Adding Django 4.0 to the unit-tests.yml matrix will now correctly
result in this error and a failing job:
`django-splash 1.2.1 has requirement Django<4.0, but you have django 4.0.8.`
The other half of this is to change other CI runners to remove their
ability to control the Django version, since it's complicated to make
this work, and we probably only need it in unit-tests.yml. Convert them
to just use `make test-requirements`.
Also:
- Simplify handling of `pip --src` by setting `PIP_SRC` (rather than our
own `PIP_SRC_DIR`, which pip ignores because `--src-dir` isn't an option
that it knows). This is needed to allow `make test-requirements` to do
the pip calls. An alternative would be to set a pip-options env var for
the make target to use, but `PIP_SRC` already exists.
- Remove outdated modifications to common_constraints
- Add comment explaining why pylint tests need dev-requirements
4.13.3 merely brings the proctoring library celery version up to date
with the platform celery version, which is already the case when
proctoring is deployed since as a plugin it does not control celery
