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
I had thought this wiki page was publicly accessible, but it
turns out that it is restricted to edX employees. Making the
page publicly visible would involve editing some queries
to remove edX.org-specific information, which is doable but
not something I can commit to right now.
This test was failing for Django 3 and during investigation it found that it isn't working as per expected due to introduction of caching. So fixed the test case to avoid caching to mimic race condition.
BOM-2799
course outline, which don't need block dates below the subsection level of a course.
Pass the course's published version to all the appropriate places where edx-when's API
is called - to allow edx-when to more efficiently cache queried/processed results.
TNL-8061
The following ModuleSystem attributes are deprecated by this change, and should be pulled directly from the user service instead:
* anonymous_student_id
* seed
* user_id
* user_is_staff
Related changes:
* Removes the `user` and `anonymous_student_id` parameters from the ModuleService constructor.
* Stores anonymous_user_id in XBlockDjangoUserService's opt_attr
* Pulls out constants used by DjangoXBlockUserService opt_attr so they can be used in the platform code.
* LmsModuleSystem uses the user service created in wrapper function for runtime.publish to avoid requiring the user
service to be "needed" by all XBlocks.
* LmsModuleSystem no longer checks for instances of XModuleDescriptor when deciding what kind of anonymous_user_id to
provide: all XModules are XBlocks, so this check is unnecessary.
* XBlockRuntime returns a user service when requested
* Adds tests for deprecated ModuleSystem attributes and changes to XBlockDjangoUserService.
* docs: ADR that documents how MFEs can access in-context discussions
This ADR proposes the mechanism for MFEs to get access to the discussion embed for units.
* Update 0005-in-context-discussion-course-blocks.rst
* Update 0005-in-context-discussion-course-blocks.rst
* Add COURSE_ENROLLMENT_CHANGED: sent after the enrollment update
* Add COURSE_UNENROLLMENT_COMPLETED: sent after the user's unenrollment
* Add CERTIFICATE_CREATED after the user's certificate generation has
been completed
* Add CERTIFICATE_CHANGED: after the certification update has been
completed
* Add CERTIFICATE_REVOKED: after the certificate revocation has been
completed
* Add COHORT_MEMBERSHIP_CHANGED: when a cohort membership update ends
If the bundle is deleted, `blockstore_cache.get_bundle_version_number(bundle_uuid)`
will raise an error.
Catch this error in `get_bundle_links`,
so the REST api doesn't crash with a 500 error when a linked bundle is deleted.
MST-970. If name affirmation is enabled, a user should only be allowed to make limited edits to their profile name before they are required to go through IDV. Right now, the allowable edits are limited to:
* add/delete/replace one character (including one space on either side)
Edits that are not allowed, and therefore require IDV include:
* changing 2 or more characters
* changing their name 3 or more times
This behavior will not be enabled until name affirmation is fully rolled out, so there should be no noticeable difference in account settings behavior at the time this is merged.
