This is a pure refactoring of cms/envs/production.py, removing several
redundant statements that have accrued over the years as the platform moved
from python-only, to python+json, to python+json+yaml, to today's python+yaml
setup.
This is the CMS version of:
* a81493ce7f
* (originally 15939232d5)
Also included:
* Add some more explicit structure to the both LMS's and CMS's
production.py using big comments.
* In both LMS and CMS settings, alphabetize the production overrides,
and remove the extraneous comments. Separate out the handful of settings
which have useful comments. The rest of the settings' comments were not
helpful--they were either just stating the obvious, or they were duplicative
of what's documented in common.py.
Co-Authored-By: Feanil Patel <feanil@axim.org>
Part of: https://github.com/openedx/edx-platform/issues/36215
Fixes the styles for the advanced editors (poll, survey, LTI Provider, etc). Updated the code if `xblock_v2/xblock_iframe.html` to use `course-unit-mfe-iframe-bundle.scss`
Blockstore and all of its (experimental) functionality has been replaced with
openedx-learning, aka "Learning Core". This commit uninstalls the now-unused
openedx-blockstore package and removes all dangling references to it.
Note: This also removes the `copy_library_from_v1_to_v2` management command,
which has been broken ever since we switched from Blockstore to Learning Core.
Part of this DEPR: https://github.com/openedx/public-engineering/issues/238
The LMS and Studio need to set values for CORS_ALLOW_HEADERS so that the
MFEs can work properly, since preflight requests will need to send over
extra headers. Prior to this commit, CORS_ALLOW_HEADERS was being
redefined in multiple places in edx-platform and again in Tutor's config
because it was only being conditionally set if ENABLE_CORS_HEADERS was
True (which was a policy setting). But CORS_ALLOW_HEADERS is application
logic in that the value is determined by what the view needs, and won't
vary by deployment.
By consolidating this to always be defined in the common.py files, we
make sure that deployment environments don't have to define it. An
example of where this bit us was when course import in the course
authoring MFE did not work because Tutor was using an outdated value for
this setting.
A followup to this would be to just rip out the ENABLE_CORS_HEADERS
setting entirely, and just always have it on. But that would benefit
from a little more discovery to make sure there's no weird use case that
still requires it to be False (maybe something in the test suite?).
Datadog was removed 6+ years ago but some settings and related keys got
left behind. Get rid of them since we don't need them and also to
prevent people from assuming it's okay to hardcode datadog settings into
our codebase.
BREAKING CHANGE: Removes all code, tests, and settings related to
indexing of V2 (blockstore-backed) content libraries in elasticsearch.
This includes indexing of top-level library metadata as well as indexing
of library block metadata. Operators who enabled the experimental
Library Authoring MFE *and* the experimental ENABLE_CONTENT_LIBRARY_INDEX
feature may notice that sorting, filtering, and searching of V2
libraries and their blocks may now be slower and/or less powerful.
The ENABLE_CONTENT_LIBRARY_INDEX feature was already disabled by
default, so most/all operators (including edx.org) should not notice
any difference.
Removed settings include:
* FEATURES['ENABLE_CONTENT_LIBRARY_INDEX']
* ENABLE_ELASTICSEARCH_FOR_TESTS
* TEST_ELASTICSEARCH_USE_SSL
* TEST_ELASTICSEARCH_HOST
* TEST_ELASTICSEARCH_PORT
For rationale, see the updated "Status" section of:
./openedx/core/djangoapps/content_libraries/docs/decisions/0001-index-libraries-in-elasticsearch.rst
Set an e-mail destination path if no overrides are provided. This
setting is only relevant when the file based email backend is in use
like it is in devstack.
As a part of this change, we render the DATA_DIR setting higher in the
settings file so we can reference it sooner but this should not impact
any other uses of this setting.
The S3BotoStorage backend was deprecated in favor of the S3Boto3Storage
backend. This change updates the default backend to use the latter.
style: This re-links and rewords a relevant comment that had been
disconnected during previous refactoring.
docs: ade79308a3/docs/backends/amazon-S3.rst (migrating-from-boto-to-boto3)
Fixes: FAL-3431
Fixes: public-engineering/128
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.
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
* fix: studio registration using the LMS SSO
Add the social-core settings:
```
INACTIVE_USER_LOGIN = True
INACTIVE_USER_URL = 'http://localhost:18010'
```
Change the registration link's `next` parameter to trigger SSO login
after the registration.
* feat: added new live provider and fixed tests
* feat: added free_tier compatiblity
* fix: resolved linter issues and other refactors
* fix: ran makemigration to generate migrations
* fix: Implemeted key retrival for tabs
Co-authored-by: AhtishamShahid <ahtishamshahid@A006-00850.local>
This code was originally located at:
./openedx/core/djangoapps/coursegraph
However, code makes more sense within the ./cms tree, because:
* it is responsible for publishing course content to an
external system, with is within the responsibilities of CMS, and
* is uses modulestore, which is discouraged for use in LMS
(see 0011-limit-modulestore-use-in-lms.rst).
So, we move the code to:
./cms/djangoapps/coursegraph
and uninstall coursegraph from LMS.
We do not expect this refactor to have any breaking downstream effects.
Most settings in the production.py files fall back to their values in
common.py if they aren't set in the yaml config files but some
historically didn't. Update them so that they are more in-line with the
rest of the settings in this file.
edx-platform supports COMPREHENSIVE_THEME_LOCALE_PATHS setting, which
appends paths to the end of LOCALE_PATHS, but there's currently no
way to add additional paths to the start of the list.
https://tasks.opencraft.com/browse/SE-5299
This is so that the lms default celery queue does not get backed up
when coursegraph is hosed (which is likely when coursegraph has been
redeployed and needs to get the full set of courses).
TNL-8386
This:
1. Introduces a variable for the Course Outline view in Studio.
A custom theme can override it to add new editors.
2. Exports a function for creating new editor modals.
A custom theme can use it to create editors without adding boilerplate code.
3. Adds a pluggable override for XBlock fields that are passed to the Studio.
Without this, custom editors in Studio cannot retrieve values of XBlock fields.
- Fixed LANGUAGE_COOKIE settings name to LANGUAGE_COOKIE_NAME beacuse later is recognised by django
- Added test to verify cookies use in dark lang middleware
- Fixing Django 3.0 tests
which can be configured from the lms/studio environment
refactor: raise ImproperlyConfigured on TypeError
Signed-off-by: Gabor Boros <gabor.brs@gmail.com>
Co-authored-by: Jillian Vogel <jill@opencraft.com>
With the PR it will load the old `CORS_ORIGIN_WHITELIST` since there is no change in `djang-cor-headers` version. In next PR this version will get upgraded.
LOGIN_REDIRECT_WHITELIST has been used to filter redirect-url while processing logout requests but its configurations were not picked through environment files like lms.yml or studio.yml. This PR fixes that bug.
Several of our cookies are meant to be shared between the LMS
and the marketing site. The previous assumption was that
SESSION_COOKIE_DOMAIN would cover both. We would like to make
it so that these can be set independently of each other.
https://openedx.atlassian.net/browse/ARCHBOM-1831
common.py has queue names that always get overridden by production.py
and lead to confusion. Set a default SERVICE_VANIANT in common.py and
then set the queue names based on that in common.py so that
production.py doesn't make it more complicated.
This should prevent the issue where if you copy a queue name in
common.py it ends up being incorrect in the production system. This is
what happened with the sample_task change.
https://github.com/edx/edx-platform/pull/23731 made it so that the queue
name for that queue is independently configurable but the default was
set to the value of HIGH_PRIORITY_QUEUE in common.py which is not the
same as the value set in production.py leading to stale tasks that never
get picked up in production.
BREAKING_CHANGE: If anyone was building a different settings file on top
of common, the default names in common.py are now change to be service
variant specific. eg 'edx.cms.core.high' instead of 'edx.core.high'
* Use config settings for olxcleaner
Use config settings instead of hardcoded values for olx validation. This would help in adding a great deal of control when you want to change these settings in the future. With this approch we would not need a redeploy.
* Use configs and deprecate waffleflag and also add / update tests
