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.
* feat: add 2 months limit in notifications list API
* chore: add NOTIFICATIONS_MAX_DAYS in lms settings
* refactor: update NOTIFICATIONS_MAX_DAYS to NOTIFICATIONS_EXPIRY
* feat: add order_by reverse id in notificationslist API
Now that we're using standard service containers, we can use a matrix to
test both the current supported versions in one job. This should also
make it easier to test with future versions as we get ready to upgrade.
If we don't make the DATA_DIR a derived_setting, the only way to
override it is to override the entirety of the MODULESTORE config, or
override DATA_DIR in common.py in your fork.
By default if you use `localhost` as the `HOST` value for mysql, it
tries to connect to a file socket on disk rather than trying to connect
to the loopback hostname. This prevents us from running MySQL in a
container while running the LMS on your local machine.
Setting the host to `127.0.0.1` forces the SQL connection to go over TCP
instead. This allows you to map your container port to your localhost
without any issues.
We did this in lms/envs/common.py in an earlier change but did not
update cms/envs/common.py at that time.
* feat: Added separate url for only returning amplitude recommendations
* chore: added extra line between serializers
* chore: changed name of methods
* chore: updated and added docstrings
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
