* refactor: moves is_content_creator
from cms.djangoapps.contentstore.helpers to common.djangoapps.student.auth
* feat: adds content tagging app
Adds models and APIs to support tagging content objects (e.g. XBlocks,
content libraries) by content authors. Content tags can be thought of as
"name:value" fields, though underneath they are a bit more complicated.
* adds dependency on openedx-learning<=0.1.0
* adds tagging app to LMS and CMS
* adds content tagging models, api, rules, admin, and tests.
* content taxonomies and tags can be maintained per organization by
content creators for that organization.
The purpose of this is to expose the assets_handler endpoint as a public endpoint as part of the studio content API MVP. This allows a course author to register an oauth application in django admin and then retrieve, create and delete assets with this endpoint. You can only update the "locked" attribute for an asset.
This PR adds a management command to delete v1 content libraries. CLI options are given for a singular library, as well as all libraries. The command raises some errors related to grading, as it uses the code to delete courses, but that is something I can live with for a quick and dirty version of this capability. Also, the pruner will have to be run later to remove any orphan blocks left behind by removing the inde
This re-applies commit 36cc415 with handling an invalid context_key in the
`PartitionService`. It can happen when rendering a `LibraryContentBlock` in
Studio because this service is initialized by the modulestore when validating
an XBlock to gather its error messages in the `studio_xblock_wrapper`.
`module-js` and `module-descriptor-js` are old JavaScript group
indicators, left over from when we managed XModule assets via Django
Pipeline. We would like to get rid of them in order to make it easier to
build XModule JS without using Python.
There is one single usage of `module-js` in the entire platform (the
rest have been replaced with Webpack references, which is the
less-outdated way of managing XModule assets :). The lone `module-js`
reference was added in 2013 [1] so that circuit diagrams would display
in the course wiki. However, the ability to render circuits in the wiki
was removed in 2015 [2], so it is safe to remove the reference.
There is also one single usage of `module-descriptor-js`. It's in the
legacy bulk email editor, which hackily cribs from the old HtmlBlock
editor. Fortunately, we are able to simply replace the Django Pipeline
reference with the equivalent XModule JS Webpack bundle. (Note: The old
email editor is currently still supported, but is currently being
replaced by frontend-app-communications, so this hack will be gone
eventually).
Finally, this commit also sneaks in one styling fix: it adds the
HtmlBlockEditor CSS back to the aforementioned legacy bulk email page.
The missing CSS was causing a read-only 1-line codemirror editor to
appear below the HTML editor [3]. This bug was introduced during the
original XModule SCSS decoupling [4], which removed builtin block CSS
from the LMS-wide bundle, thus removing the HTML editor CSS from the
bulk email page. We imagine that nobody noticed because the bug only
exists in master (not Palm) and frontend-app-communications seems to be
globally enabled on edx.org. As a simple fix, we add the new CSS link to
the legacy bulk email page, and it renders fine again [5].
References:
1. 3fc59b3da5
2. https://github.com/openedx/edx-platform/pull/10324
3. Before fix: https://github.com/openedx/edx-platform/assets/3628148/25fc41b2-403d-4339-8c49-0b04664dfa02
4. https://github.com/openedx/edx-platform/pull/32018
5. After fix: https://github.com/openedx/edx-platform/assets/3628148/9a5d74f1-cc83-4ebe-8f0c-ee270f7721b8
Part of: https://github.com/openedx/edx-platform/issues/32481
* get rid of six.text_type(s)
* get rid of six.b()
* get rid of six.string_types
* get rid of six.PY2/six.PY3
* get rid of six.iteritems() and six.viewvalues()
* Revert "feat: remove `field-data` service from runtime initialization"
This reverts commit 6c435bb68c.
* Revert "feat: remove field data binding from the runtime"
This reverts commit 5f46ea52cd.
Add ability to roll-forward ORA flex peer grading feature. Where enabled
for an Organization or course, flex peer grading will be turned on at the
course level for new course runs and course reruns. Where disabled,
a new course or course rerun will preserve existing / default setting
value.
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
This PR addresses the renaming of the contentstore/xblock_services folder to contentstore/xblock_storage_handlers as a follow-up to PR #32282. The renaming is done to prevent naming conflicts with xblock runtime services and to make the purpose of the files more understandable. The file xblock_service.py has been renamed to view_handlers.py to better reflect its functionality.
Justification and Future Refactoring Outlook:
The xblock_storage_handlers folder contains service methods that implement the business logic for view endpoints located in contentstore/views/block.py. It is renamed to xblock_storage_handlers to reflect its responsibility of handling storage-related operations of xblocks, such as creation, retrieval, and deletion.
The view_handlers.py file includes business methods called by the view endpoints. These methods, such as handle_xblock, delete_orphans, etc., interact with the required modulestore methods, handle any errors, and aggregate and serialize data for the response.
The term 'handler' in the context of 'view_handlers.py' represents methods that facilitate business logic for view endpoints. It is critical to note the distinction between these 'handler methods' and the xblock_handler method. The xblock_handler is a view endpoint itself, residing in contentstore/views/block.py, and is well known in this context. Although its name might suggest otherwise, it is not a handler in the sense of the 'handler methods' we've defined in 'view_handlers.py'. To maintain consistency with existing naming conventions, it remains as xblock_handler.
* refactor: improve typing of StaticFile named tuple
* feat: copy static asset files into the clipboard
* feat: paste static assets
* feat: show notification in studio about pasted assets
* fix: HTML XBlocks would lose the editor="raw" setting when copy-pasted.
* feat: copy python_lib.zip to the clipboard when it seems to be in use
BREAKING CHANGE: This removes the following deprecated shims from the runtime:
`replace_urls`, `replace_course_urls`, `replace_jump_to_id_urls`. XBlocks need
to use the `replace_urls` service instead.
* feat: add xblock endpoint for updating an xblock
fix: remove debugger
feat: make function call more generic
refactor: just use request.json for request data as before
refactor: extract method
fix: revert wrong method change
fix: refactor correct method
feat: use handle_xblock method so that we can do more than update xblocks
fix: usage_key_string defaults to None
add all CRUD operations
fix usage key parameter
refactor: create /views folder
refactor: move xblock view functions to xblock_services
fix: tests
fix: tests
refactor: move xblock API endpoint to contentstore
* docs: add explanatory comment to new xblock_service
* feat: add feature flag for enabling content editing api
* feat: raise 404 if studio content api is disabled
* tests: test xblock endpoint
* test: make all post tests work
* test: check that xblock_handler receives correct args
* refactor: create util mixin for course factories with staff
* refactor: extract course staff authorization tests
* refactor: extract tests to api view testcase class
* test: add get tests
* test: fix tests
* test: fix tests
* test: fix tests
* test: add all crud tests
* fix: refactor to fix tests
* fix: merge conflict
* fix: merge conflict
* fix: tests after merge
* fix: json request decorator
* fix: lint
* fix: lint
* fix: lint
* fix: lint
* fix: new test files
* fix: lint
* fix: lint and apply PR suggestions
* fix: lint
* fix: lint
* fix: lint
* fix: lint
* fix: lint
* fix: lint
This makes a couple of changes to the xblock handler in the CMS. These changes
add a handful of utility functions and modify the existing ones to make reuse
of existing blocks easier. With these changes, it is possible to copy an
entire section from one course to another, and then later refresh that section,
and all of its children, without destroying the blocks next to it.
The existing _duplicate_block function was modified to have a shallow keyword
to avoid copying children, and the update_from_source function was added to
make it easy to copy attributes over from one block to another. These functions
can be used alongside copy_from_template in the modulestore to copy over blocks
and their children without requiring them to be within any particular container
(other than a library or course root)-- thus allowing library-like inclusion
without the library content block. This is especially useful for cases like
copying sections rather than unit content.
An exam due date can be inferred from the end date of the course if the exam does not have a due date. In the legacy proctoring system (the edx-proctoring plugin), this inference is made in the proctoring code by calling the edx-when API. This is possible because edx-proctoring is a plugin that's installed into the edx-platform, into which edx-when is also installed.
In the new exams service, we do not want to call to the LMS to get due date information from edx-when. This poses a number of problems, not all of which are solved by this commit. This commit allows the exams service to infer a due date for an exam if that exam does not have a due date at the subsection level.
Note that this is a departure from edx-proctoring. This also opts out exams powered by the new edx-exams service from personalized learner schedules (PLS)/relative dates, because we no longer consider the pacing type of the course.
