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
Current behavior for both old and new exams paths on exam creation is
that the signal fires, the update code kicks off a celery task which
looks for a new exam, and that exam is not found so no actual update
is done. Or the old version is visible but the updated version is not.
By waiting until the change is actually committed, we should find the
new exam when we search for it.
This is currently an invisible bug just because of the large numbers
of updates that working on a course provides, the exam will be correct
unless it was the absolute last thing that was touched, in which case
it will be out of date.
https://github.com/openedx/edx-platform/pull/31261 fixed celery
cache behavior when not running a worker and made sure production
would keep the old cache behavior, but missed these secret alternate
settings files, bring them up to date.
Also fixes the cms file to have the actual broker URL.
It includes support for course enrollment in case of enrollment_end date has passed or the upgrade_deadline has passed. The force_enrollment argument is used to support this functionality, and can_upgrade and include_expired will be True if force_enrollment is True. Only a user who has GlobalSupport access can perform this operation.
* refactor: make _credit_status function public
This allows for reuse in the new learner home
* feat: add credit to learner home serializers
* feat: get credit statuses for learner home
For edx.org, this will be set to <https://www.edx.org/policy/security>.
The only theme that I'm aware of as supporting this is `edx.org-next` but
other deployments might use this `get_footer` call as well.
This test stopped throwing the `TransactionManagementError` once we added the
`site_configuration.get_value()` call to the language preferences middleware.
This feature was implemented in b01544d690 to replace the session's language
in the request. 44ddbdf925 moved the process from the request to the response,
which made this feature unusable (because the request was already processed).
44ddbdf925 also made this feature set the language cookie. However, it is
overwritten by user preferences.
To fix this, we could overwrite the cookie of the response after it's set from
user preferences. However, it is not an ideal solution because when users
switch between Sites with different languages, the first response will use the
language of the previous page. Therefore, this ignores user preferences and
alters the cookie of a request instead.
CMS youtube transcript tests call GET twice & need different responses on each of the two calls
Current solution (setup_caption_responses) decides what to return on basis of call number.
Former solution (mock_request_get()) decided what to return on the basis of kwargs, which would differ on first vs. second call
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
