* feat: add notifications mark as read API
* chore: update description for mark as read notification URL
* refactor: resolve pylint issue
* refactor: notifications mark as read API and test cases
* feat: add translated messages in notificationsAPI response
`xmodule_assets` generated a series of SCSS "entrypoint"
files, where each entrypoint file imported from the
SCSS "sources" in xmodule/css.
This process was more complicated up until very
recently (see PRs in issue linked below for more
context). Now that the process is simpler, though,
there is no reason to generate the SCSS entrypoints;
we can just commit them to the repository instead!
So, we go from this:
# GENERATED: SCSS entrypoints files for CMS
common/static/xmodule/descriptors:
AboutBlockStudio.scss
AnnotatableBlockStudio.scss
...
# GENERATED: SCSS entrypoints files for LMS
common/static/xmodule/modules:
AboutBlockPreview.scss
AnnotatableBlockPreview.scss
...
# VERSION CONTROLLED: SCSS source files
xmodule/css:
annotatable/...
capa/...
...
to this:
# VERSION CONTROLLED: All XModule SCSS
xmodule/static/sass:
# Source files
include:
annotatable/...
capa/...
...
# CMS entrypoint files
cms:
AboutBlockStudio.scss
AnnotatableBlockStudio.scss
...
# LMS source files
lms:
AboutBlockPreview.scss
AnnotatableBlockPreview.scss
...
Also, we are able to remove all SCSS-related logic from the
`xmodule_assets` script and from the `HTMLSnippet` class.
XModule JS assets still need processing, but we will address
those in a separate series of PRs.
Part of: https://github.com/openedx/edx-platform/issues/32292
* 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
[APER-2504]
This is a companion to PR #32458. This updates the `notify_credentials` management command and adds an additional argument/switch (`--revoke_program_certs`).
If included, this option will be converted to a boolean and passed as a script option. Eventually, the `send_notifications` function (updated in the previously mentioned PR) will determine if we should fire a signal that checks if any program certs need to revoked.
[APER-2504]
This PR adds additional functionality to the tasks kicked off when the `notify_credentials` management command is run.
I have added a new keyword arg (revoke_program_certs) that, if True, will check to see if we need to revoke a program certificate. This functionality was introduced to help automate fixing cases where a learner still has access to a Program Certificate even if they have been awarded all of the course certificates in a Program (see APER-2499).
The functionality has to be committed in two separate PRs because of our blue/green deployments. The task changes will come first, then we will update the management command to be able to set/pass the new settings. New settings were added as keyword args (defaulting to False) in order to ensure that we won't trip up our workers.
The `xmodule_assets` command copies SCSS source files from
xmodule/css to common/static/xmodule/scss, renaming them
to `{MD5_HASH}.scss` in order to "remove duplicates".
The copied files are then included into the generated
SCSS entrypoint files (eg AnnotatableBlockStudio.scss).
The "de-deplication" is completely unnecessary: there are
only a couple dozen SCSS files, and none of them are duplicates.
This copying process is confusing, it complicates our
build process, and it makes our SCSS harder to understand.
So, in the generated SCSS entrypoint files, we
stop importing the *copied* SCSS sources, and just
import the *original* SCSS sources instead.
For example, common/static/xmodule/descriptors/scss/AboutBlockStudio.scss
is changed from:
.xmodule_edit.xmodule_AboutBlock {
@import "9bdcda00f046f78be79aca7791e1d4fb.scss";
@import "a10fc3e0fd6aca63426a89e75fe69c31.scss";
}
to:
.xmodule_edit.xmodule_AboutBlock {
@import "editor/edit.scss";
@import "html/edit.scss";
}
In order to make the `@import` lines work, we add xmodule/css to the list
of lookup dirs for XModule SCSS compilation. We also remove the
copying logic from `xmodule_assets`, as it is no longer needed.
Part of: https://github.com/openedx/edx-platform/issues/32292
Some of the static_template_view tests use names to get the URLs for the
error pages for testing, so I added names and updated the test to match
the new names.
I also updated the `test_404` function because we're no longer rendering
the 404 page in a different way from the 500 page so the response
includes the correct response code and content type. This reduces the
number of differences between the 404 handler and the 500 handler.
We were adding paths for the error pages in two places so one of them
simply wasn't being used. The lms urls.py also covered the 429 wich the
static_templates_view urls.py did not cover. We don't need both and we
need the definition of the handlerNNN variables in urls.py to override
the default django error views so I'll leave just those.
I also made the `exception` parameter for the `render_404` function
optional by adding a default value. We don't use the exception when
rendering the 404 page but the exception argument is a part of the
default method signature for the function that `render_404` replaces so
I didn't want to remove it and cause issues when django tries to call
this function.
