- New exported courses include course run information in:
- `url_name` of root course node
- file name of root node in course folder
- root key name in policy.json
- directory name inside policies folder
- when imported via management command, the OLX will overwrite an
available existing course with the same course key (i.e. same org,
course number and course run)
- if there is no matching course, one will be created
- when imported via the studio web ui (or import API), the OLX will
replace the current course (no change in behavior)
- courses exported with this commit have been tested to import via
management command and studio web UI in hawthorn and ginkgo releases.
They should also work in prior releases, but have not been tested.
Observed Problems:
1. Discussion categories and targets were missing
2. When imported over existing course Discussion IDs have changed unexpectedly - all posts were missing
Solutions:
* Parsing legacy discussion OLX
* Do not force exporting discussion ID
[PERF-303] Integer XBlocks/XModules into the static asset pipeline.
This PR, based on hackathon work from Christina/Andy, implements a way to discover all installed XBlocks and XModules and to enumerate their public assets, then pulling them in during the collectstatic phase and hashing them. In turn, the methods for generating URLs to resources will then returned the hashed name for assets, allowing them to be served from nginx/CDNs, and cached heavily.
- adaptation asides to be imported from the XML
- updating SplitMongo to handle XBlockAsides (CRUD operations)
- updating Studio to handle XBlockAsides handler calls
- updating xblock/core.js to properly init XBlockAsides JavaScript
We had a bug where mixins weren't being applied before `load_from_xml`
was called. This meant that not all of the fields were being loaded
correctly. To fix it, we used the mixoligist from the runtime to apply
the mixins earlier in the process. However, that caused the mixins to be
applied twice.
The included fixes to xblock resolved the multiply-applied mixins, and
the fixes to the parsing code make it simpler to understand, and add
some unit tests of the parsing to boot.
Instead, we use XModule field default values when creating an empty
XModule. Driven by this use case, we also allow for XModules to be
created in memory without being persisted to the database at all. This
necessitates a change to the Modulestore api, replacing clone_item with
create_draft and save_xmodule.