Split modulestore persists data in three MongoDB "collections": course_index (list of courses and the current version of each), structure (outline of the courses, and some XBlock fields), and definition (other XBlock fields). While "structure" and "definition" data can get very large, which is one of the reasons MongoDB was chosen for modulestore, the course index data is very small.
By moving course index data to MySQL / a django model, we get these advantages:
* Full history of changes to the course index data is now preserved
* Includes a django admin view to inspect the list of courses and libraries
* It's much easier to "reset" a corrupted course to a known working state, by using the simple-history revert tools from the django admin.
* The remaining MongoDB collections (structure and definition) are essentially just used as key-value stores of large JSON data structures. This paves the way for future changes that allow migrating courses one at a time from MongoDB to S3, and thus eliminating any use of MongoDB by split modulestore, simplifying the stack.
- 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
This was causing issue with Django 3.2, as Django has restricted to only use language from the pre-defined set of languages provided by Django.
BOM-2870
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>
created CustomPagesCourseApp class
feat: created custom pages course app plugin
created CustomPagesCourseApp class
added CUSTOM_PAGES_HELP_URL to lms and cms settings
added entry point to setup.py
feat: added toggle to ENABLE_CUSTOM_PAGES in lms and cms settings
feat: removed the option to enable/disable the availability of custom pages course apps.
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.
- Removed manage_user and manage_group commands and their unit tests from edx-platform and added then to edx-django-utils.
- Modified User.post_save signal to ensure the user profile is created when manage_user management command is run to create a user.
- Added edx-django-utils to INSTALLED_APPS for LMS and Studio.
- Moved generate_password from openedx.core.djangoapps.user_authn.utils to edx_django_utils.user along with its unit test.
This also requires using different session cookie names in devstack for
LMS and Studio so that we can properly use the OAuth flow locally, rather
than just sharing a session cookie on the localhost domain. (Note that
ports are not used for cookie segmentation in browsers.)
This depends on the following provisioning PR:
https://github.com/edx/devstack/pull/825
Instead of hard-coding the "Learn More" and potentially other links for course
apps in the course authoring MFEs this change loads those URLs from the
django settings as part of each individual course app.
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.
feat: reimagine certificate display settings
The course settings `certificate_available_date` (CAD) and
`certificates_display_behavior` (CDB) were previously
acting indedependantly of one another. They now work in
tandem. This change:
- limits CDB to a dropdown
- removes "early_with_info" and adds "end_with_date"
- only takes CAD into account if "end_with_date" is selected
- Moves CDB to the main course schedule settings page
- updates CourseOverview model and CourseDetails objects to
validate these fields and choose sane defaults if they aren't
expected values
This work was previously done in bd9e7dd (complete with bugs), so this
version is toggleable via the ENABLE_V2_CERT_DISPLAY_SETTINGS setting
With Badgr v2 API, notification emails for earning badges are
no longer sent to learners by default. However, the request to
create a badge assertion accepts an optional boolean property
"notify", that can be used to enable/disable email notifications.
Make it configurable by an optional setting `BADGR_ENABLE_NOTIFICATIONS`
(defaults to False).
for Chrome version 92. This token is added to the courseware iFrame, which
enables the iFrame to retain the ability to summon modals & alerts - or open
new windows via JS. This token has a limited lifespan - it currently expires around
Dec 14, 2021.
TNL-8559
