- Returns top parent key instead of boolean in upstream info api
- Adds edited_on raw time in course outline api
- Adds has_changes to course details api
Python-evaluated problems were failing to render because they were trying to
invoke `course_id.make_asset_key` in order to obtain the asset key of the
custom Python ZIP file. Learning Core assets work differently (no asset keys,
etc.), and, furthermore, we haven't really thought though how and whether we
want to support custom Python ZIPs in libraries.
So, this fix punts on supporting Python ZIP files in libraries for now, but
enables rendering of advanced CAPA problems which don't rely on a ZIP. This
brings us to parity with Legacy Libraries, which didn't support assets at all
and thus didn't support Python ZIPs either.
Fixes: https://github.com/openedx/edx-platform/issues/37447
* refactor!: use String field instead of Dict field to store top_level_downstream_parent_key
Since this is a new field no production instance should have this field
yet. Developers need to delete their old courses as this change will
raise error in all course pages.
* chore: add `top_level_parent` field in ComponentLink and ContainerLink admin
* refactor: use ":" as separator
* refactor: block key parsing and tests
In the effort to simplify settings in edx-platform, as discussed in ADR 22 -
Settings Simplification, this PR brings some of the production defaults defined
in `lms/envs/production.py` and `cms/envs/production.py` up to
`openedx/envs/common.py` or `lms/envs/common.py` and `cms/envs/common.py` as
appropriate.
Bringing these defaults up from the `production.py` settings modules caused
changes in the rendered settings of the `test.py` modules, and so I have
settings to the `test.py` modules to bring the rendered settings back in line
with what is has been. I have not deeply looked at which settings are needed
for tests to pass or not, but just the differences between the rendered
settings between `master` and this branch.
ADR 22: https://github.com/openedx/edx-platform/blob/master/docs/decisions/0022-settings-simplification.rst
Fixes https://github.com/openedx/edx-platform/issues/36892.
Since all built-in block Sass is gone, we remove two final pieces of code:
* the steps in `npm run compile-sass` which compiled `xmodule/assets`, and
* the now-unused `add_sass_to_fragment` function.
This should speed up the edx-platform assets build a little bit.
This commit also includes some minor dev doc updates.
Part of: https://github.com/openedx/edx-platform/issues/35300
After we merged this PR: https://github.com/openedx/edx-platform/pull/33920
this error began popping up in logs:
Unable to load XBlock 'staffgradedxblock'
....
ImportError: cannot import name 'get_course_blocks' from
partially initialized module 'lms.djangoapps.course_blocks.api'
(most likely due to a circular import) ...
The root cause was the new imports of `derived_key` and `BlockKey` into
xmodule/library_content_block.py. Those new imports come from
xmodule/modulestore/store_utilities.py, which runs
`XBlock.load_classes()` at the module level, which fails because we are
still in the process of loading xmodule/library_content_block.
As a solution, we move both `derived_key` and `BlockKey` to
xmodule/util/keys.py. We could potentially move that file to opaque-keys
eventually, depending on how well we think that those concepts generalize.
Also:
* We rename the function from derived_key to derive_key, as
functions should be verbs.
* We combine the first to parameters of derive_key (a source ContextKey
and a source BlockKey) into a single parameter (a source UsageKey). In
my opinion, this makes the function call easier to understand.
In ~Palm and earlier, all built-in XBlock Sass was included into LMS and CMS
styles before being compiled. The generated CSS was coupled together with
broader LMS/CMS CSS. This means that comprehensive themes have been able to
modify built-in XBlock appearance by setting certain Sass variables. We say that
built-in XBlock Sass was, and is expected to be, "theme-aware".
Shortly after Palm, we decoupled XBlock Sass from LMS and CMS Sass [1]. Each
built-in block's Sass is now compiled into two separate CSS targets, one for
block editing and one for block display. The CSS, now located at
`common/static/css/xmodule`, is injected into the running Webpack context with
the new `XModuleWebpackLoader`. Built-in XBlocks already used
`add_webpack_to_fragment` in order to add JS Webpack bundles to their view
fragments, so when CSS was added to Webpack, it Just Worked.
This unlocked a slieu of simplifications for static asset processing [2];
however, it accidentally made XBlock Sass theme-*unaware*, or perhaps
theme-confused, since the CSS was targeted at `common/static/css/xmodule`
regardless of the theme. The result of this is that **built-in XBlock views will
use CSS based on the Sass variables _last theme to be compiled._** Sass
variables are only used in a handful of places in XBlocks, so the bug is subtle,
but it is there for those running off of master. For example, using edX.org's
theme on master, we can see that there is a default blue underline in the Studio
sequence nav [3]. With this bugfix, it becomes the standard edX.org
greenish-black [4].
This commit makes several changes, firstly to fix the bug, and secondly to leave
ourselves with a more comprehensible asset setup in the `xmodule/` directory.
* We remove the `XModuleWebpackLoader`, thus taking built-in XBlock Sass back
out of Webpack.
* We compile XBlock Sass not to `common/static/css/xmodule`, but to:
* `[lms|cms]/static/css` for the default theme, and
* `<THEME_ROOT>/[lms|cms]/static/css`, for any custom theme.
This is where the comprehensive theming system expects to find themable
assets. Unfortunately, this does mean that the Sass is compiled twice, both
for LMS and CMS. We would have liked to compile it once to somewhere in the
`common/`, but comprehensive theming does not consider `common/` assets to be
themable.
* We split `add_webpack_to_fragment` into two more specialized functions:
* `add_webpack_js_to_fragment` , for adding *just* JS from a Webpack bundle,
and
* `add_sass_to_fragment`, for adding static links to CSS compiled themable
Sass (not Webpack). Both these functions are moved to a new module
`xmodule/util/builtin_assets.py`, since the original module
(`xmodule/util/xmodule_django.py`) didn't make a ton of sense.
* In an orthogonal bugfix, we merge Sass `CourseInfoBlock`, `StaticTabBlock`,
`AboutBlock` into the `HtmlBlock` Sass files. The first three were never used,
as their styling was handled by `HtmlBlock` (their shared parent class).
* As a refactoring, we change Webpack bundle names and Sass module names to be
less misleading:
* student_view, public_view, and author_view: was `<Name>BlockPreview`, is now
`<Name>BlockDisplay`.
* studio_view: was `<Name>BlockStudio`, is now `<Name>BlockEditor`.
* As a refactoring, we move the contents of `xmodule/static` into the existing
`xmodule/assets` directory, and adopt its simper structure. We now have:
* `xmodule/assets/*.scss`: Top-level compiled Sass modules. These could be
collapsed away in a future refactoring.
* `xmodule/assets/<blocktype>/*`: Resources for each block, including both JS
modules and Sass includes (underscore-prefixed so that they aren't
compiled). This structure maps closely with what externally-defined XBlocks
do.
* `xmodule/js` still exists, but it will soon be folded into the
`xmodule/assets`.
* We add a new README [4] to explain the new structure, and also update a
docstring in `openedx/lib/xblock/utils` which had fallen out of date with
reality.
* Side note: We avoid the term "XModule" in all of this, because that's
(thankfully) become a much less useful/accurate way to describe these blocks.
Instead, we say "built-in XBlocks".
Refs:
1. https://github.com/openedx/edx-platform/pull/32018
2. https://github.com/openedx/edx-platform/issues/32292
3. https://github.com/openedx/edx-platform/assets/3628148/8b44545d-0f71-4357-9385-69d6e1cca86f
4. https://github.com/openedx/edx-platform/assets/3628148/d0b7b309-b8a4-4697-920a-8a520e903e06
5. https://github.com/openedx/edx-platform/tree/master/xmodule/assets#readme
Part of: https://github.com/openedx/edx-platform/issues/32292
Now that all XModule SCSS is located in xmodule/static/sass,
it would make sense to co-locate the CSS there as well.
We also add a README to explain the purpose of this new folder.
In the future, we will move xmodule/js and xmodule/assets
into xmodule/static as well.
Part of: https://github.com/openedx/edx-platform/issues/32292
Similar to https://github.com/openedx/edx-platform/pull/32287,
this change removes another unnecessary step from the
`xmodule_assets` script. The script, which generates XModule
SCSS "entrypoint" files (synthesizing one or more "source" SCSS
resources), was appending MD5 hashes to each SCSS entrypoint filename:
common/static/xmodule/descriptors/scss:
AboutBlockStudio.768623f4d8d73dfb637fc94583adb990.scss
...
WordCloudBlockStudio.d41d8cd98f00b204e9800998ecf8427e.scss
common/static/xmodule/modules/scss:
AboutBlockPreview.05a6cbd5c10100a245fa2cbf151b9770.scss
...
WordCloudBlockPreview.7b899a56a70d29c58cf14b7e1888a0ec.scss
It's unclear why these MD5 hashes needed to be appended.
A comment in xmodule/static_content.py hints that it might have
something to do with de-duplication, but that doesn't make any sense,
because each XModule has exactly two SCSS entrypoint files (one for
studio_view and one for other student/author_views) and none of those
entrypoint files can possibly be shared between XModules.
Soon, as part of deleting the `xmodule_assets` script,
we would like to just check these SCSS files into version control
rather than generating them. In order to do that, we will need to
drop the hashes. This commit does that.
The new output looks like this:
common/static/xmodule/descriptors:
AboutBlockStudio.scss
...
WordCloudBlockStudio.scss
common/static/xmodule/modules:
AboutBlockPreview.scss
...
WordCloudBlockPreview.scss
Part of: https://github.com/openedx/edx-platform/issues/32292
This basically changes how the xmodule static files are
generated and consumed in order to separate the Xblock
styles from general style files. Includes:
* build: decople XModule style assets by using a custom webpack loader
* build: move scss imports to its specific file
* build: fix: add system dirs to theme lookup paths. (fixes attempt 1)
* build: fix: use bootstrap variables instead of lms variables (fixes attempt 2)
This is an amendment to #32188,
which itself was an amendment to #32018.
Addressing the issue https://github.com/openedx/edx-platform/issues/31624
This basically changes how the xmodule static files are
generated and consumed in order to separate the Xblock
styles from general style files. Includes:
* build: decople XModule style assets by using a custom webpack loader
* build: move scss imports to its specific file
* build: fix: add system dirs to theme lookup paths.
This is an amendment to #32018
Addressing the issue #31624
This basically changes how the xmodule static files are
generated and consumed in order to separate the Xblock
styles from general style files. Includes:
* build: decople XModule style assets by using a custom webpack loader
* build: move scss imports to its specific file
Addressing the issue https://github.com/openedx/edx-platform/issues/31624
- Moving xmodule folder to root as we're dissolving sub-projects of common folder in edx-platform
- More info: https://openedx.atlassian.net/browse/BOM-2579
- -e common/lib/xmodule has been removed from the requirements as xmodule has itself become the part of edx-platform and not being installed through requirements
- The test files common/lib/xmodule/test_files/ have been removed as they are not being used anymore
