Page Comparison

...

• ProblemBlock specific ones: https://github.com/edx/edx-platform/blob/master/common/lib/xmodule/xmodule/capa_base.py#L128-L269

• Ones mixed in for all block types to inherit (start dates, due dates, etc.: https://github.com/edx/edx-platform/blob/master/common/lib/xmodule/xmodule/modulestore/inheritance.py#L34-L233

Whenever a field is defined with scope=Scope.settings, it ends up in the giant structure document. When a field is defined with scope=Scope.content(e.g. problem text, list of inputs, correct answers–all of which are stored under the data field in ProblemBlock), it gets stored on a per-block/module basis in definition documents (modulestore.definitions collection in MongoDB). The original split between content and settings fields was intended to facilitate exactly this kind of re-use, where a piece of content is stored separately from the settings associated with its use in a particular course. Unfortunately, it’s not this clean in practice, because fields that were added later that probably should have been content-scoped ended up being settings-scoped instead (e.g. markdown, source_code, use_latex_compiler).

...

There are a couple of important caveats though:

1. Missing Markdown
   It can’t copy over the markdown for a problem because while that field is declared in the settings scope, it should be a content scope. In particular, editing it will try to update the value of the problem’s XML, which is stored as content scope. So you can edit it, but you can’t meaningfully override the setting without also editing the content–and remember, the Library and Course are still pointing to the same definition document. Making it so that the definitions are separable is a lot more work, so the hack was to always strip the value for markdown when copying into a course.

2. Missing in OLX
   The default values in the Course’s version of the problem do not export in OLX. Only the overridden field values get exported. This is part of the reason why the import process was modified to refresh those values from the library. If you exported from one course and into another, there would be no other way to get at the Library-set defaults, because the OLX wouldn’t carry over that data. Unfortunately, this was kind of a giant hammer that always grabs the latest version from the library for that metadata. On the bright side, I believe that the giant hammer-that-ignores-versions means that if you copy the library to the new instance first, things should “work”.

Could we just always export the defaults as fields, to carry that data across different instances of Open edX? Maybe. I’ll write more about that in the “where do we go from here” part of this multi-post. But the complicating issues are that:

...