Gate access to exam content by requiring an access token. This is a signed JWT issued by the edx-exams service that grants a user access to a sequence locator for a short lived window while an exam is in progress. This feature only applies to courses using the new exam service instead of edx-proctoring.
* feat: added mobile skus in course mode
* fix: changed api
---------
Co-authored-by: jawad-khan <jawadkhan444@gmail.com>
Co-authored-by: Robert Raposa <rraposa@edx.org>
[APER-2240]
The monolith no longer needs to understand how to build URLs to the Learner Record MFE. The Credentials IDA has logic to determine if (and how) a request should be redirected to this MFE. This PR remove unused settings from edx-platform.
We have already removed the use of these settings in #31672.
* feat: add experimental redirect for Learner Home
As a request by Data, this system repeatably groups users into
experiment groups. Based on end of user ID, users that fall beneath a
threshold (LEARNER_HOME_MFE_REDIRECT_PERCENTAGE) will be redirected to
the Learner Home experience, if enabled. Otherwise, learners will see
the legacy dashboard.
* feat: add learner home redirect percentage setting
Adds LEARNER_HOME_MFE_REDIRECT_PERCENTAGE to common settings to avoid a
failed lookup. Can be overridden through config.
* refactor: change test to not leak implementation
* feat: added apis for discussions tours
* fix: resolved linter issues
* feat: moved config list to settings and fixed unit tests
* refactor: merged migrations in 1 file
We run atomic-requests in almost all environments (for the lms and cms
anyway) EXCEPT devstack_with_worker. Using a different setting means
that even if you think you are testing with a worker like real deploys
use, you are not actually testing with the data a worker would
actually see.
The removed code also claims that if you run with atomic transactions
and a worker you will deadlock the system. If so edx.org would be
deadlocked at all times and yet is not. The old code was vintage 2015
and its assumptions probably haven't been examined since then.
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.
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 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.
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.
[APER-1941]
* update new `update_certificate_available_date_on_course_update` task to use dedicated credentials queue (like the other import Credentials tasks)
Call into the exam service instead of the edx-proctoring plugin on course publish if the course_apps.exams_ida course waffle flag is enabled. This is an early step in moving away from edx-proctoring
