* feat: Adds discussions settings for new discusions experience
This commit adds new discussions settings for the new discussions experience. These are stored in the course so they can be a part of course import/export flow.
These are also added to the discussions configuraiton API to allow MFEs to update the settings.
The discussions API is currently available via LMS, however that means it cannot save changes to the modulestore. This also adds the API to the studio config so it can now also be accessed from studio and be used to save course settings.
* fix: tests
This commit adds new discussions settings for the new discussions experience. These are stored in the course so they can be a part of course import/export flow.
These are also added to the discussions configuraiton API to allow MFEs to update the settings.
The discussions API is currently available via LMS, however that means it cannot save changes to the modulestore. This also adds the API to the studio config so it can now also be accessed from studio and be used to save course settings.
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.
This commit starts writing course indexes (active_versions) to both MySQL and Mongo, but continues to read from MongoDB only.
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.
[MICROBA-1520]
- Update course dashboard to check its context for unack'd notices from the notices app. If so, redirect the learner to the first unack'd notice.
(reintroduces earlier changes that were reverted)
The GA transformer adds the context.course_id property of a tracking
log event to the event transmitted automatically to Segment in the
"label" property, so GA can use it. This adds it also to the
"courserun_key" property, so that regular users of Segment events can
also query it in a more consistently-named property. However, it does
so only if it is a valid CourseKey.
For DENG-997.
Add CourseKey parsing.
[MICROBA-1520]
- Update course dashboard to check its context for unack'd notices from the notices app. If so, redirect the learner to the first unack'd notice.
* fix(program-portals): prevent resume course links from 404ing
From time to time course teams will delete a problem in an active
course. When this happens and that particular problem is the last
completed subsection for a learner, some naive attempts to provide a
"continue course" that takes the learner back to where they left off
may result in 404s. This checks whether a learner would be able to
access the block returned from completion data before we try to create
a link to that part of the course structure to hand to that learner.
It's used on the Master's program learner portal pages.
JIRA:EDUCATOR-5313
Co-authored-by: Zach Hancock <zhancock@edx.org>
Includes:
- general documentation
- links to individual events definitions and location
- adding examples to events docs
- adding annotations at the trigger location
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.
rest-condition has not been updated for a while, and with DRF 3.9 it is no longer needed since the ability to combine Permission classes using boolean operators is now provided by DRF directly.
Imlements OEP-15 by adding two fields to the course settings:
- Course-wide Custom JS
- Course-wide Custom CSS
The resources defined in these fields will be rendered in all course pages.
Rebase b6cb629849..0578e1c4c6 onto b6cb629849:
- Add course-wide resources to API for MFE use
- Revert "Add course-wide resources to API for MFE use" reverts commit 53648dcf0afe3cd171c9dc2eb5e56b871b2bcfb2
Signed-off-by: Gabor Boros <gabor.brs@gmail.com>
The current admin UI for the PendingNameChange model has no useful info and is not performant on edit form. This change make the view and edit of the model easier in django admin
Co-authored-by: Simon Chen <schen@edx-c02fw0guml85.lan>