added management command to clear out excessive records for API log table
Commit generated by workflow `openedx/edx-platform/.github/workflows/upgrade-one-python-dependency.yml@refs/heads/master`
Since `make pull_translations` is now performed at build time (in the new
Atlas workflow), it will generally only have access to base dependencies.
However, it depends on the `i18n_tools` command that was only installed at
the testing layer. This moves the dependency from testing to base.
(There is no increase in artifact size, as ora2 already depends on it and
is installed at the base later.)
This also adds `API_ACCESS_MANAGER_EMAIL` to the minimal settings
so that `make pull_translations` can be run using production envs in a
local environment (to test the lack of dependency on developer-level deps.)
This supports OEP-58.
This moves the Content Libraries V2 backend from Blockstore [1] over to
Learning Core [2] For high-level overview and rationale of this move, see
the Blockstore DEPR [3]. There are several follow-up tasks [4], most notably
adding support for static assets in libraries.
BREAKING CHANGE: Existing V2 libraries, backed by Blockstore, will stop
working. They will continue to be listed in Studio, but their content
will be unavailable. They need to be deleted (via Django admin) or manually
migrated to Learning Core. We do not expect production sites to be in
this situation, as the feature has never left "experimental" status.
[1] https://github.com/openedx-unsupported/blockstore
[2] https://github.com/openedx/openedx-learning/
[3] https://github.com/openedx/public-engineering/issues/238
[4] https://github.com/openedx/edx-platform/issues/34283
feat: unlink canvas user if decommissioned on canvas side
Commit generated by workflow `openedx/edx-platform/.github/workflows/upgrade-one-python-dependency.yml@refs/heads/master`
Added channel_name for api call logs records
Commit generated by workflow `openedx/edx-platform/.github/workflows/upgrade-one-python-dependency.yml@refs/heads/master`
* feat: make FA form error messaging more descript
* chore: quality
* fix: split up tests
* fix: make test more specific
* chore: fix comment typo
* chore: fix comment typo
This commit adds some supplemental, more verbose logging to the results_callback view in the verify_student Djangoapp. This endpoint is called by identity verification (IDV) providers to POST an IDV review to edX.
We are experiencing issues with receiving IDV reviews from our IDV provider, and these logs will help us diagnose whether there is an issue in edX's systems.
These logs will be removed after our investigation is complete.
enterprise version bump 4.11.12
Commit generated by workflow `openedx/edx-platform/.github/workflows/upgrade-one-python-dependency.yml@refs/heads/master`
See discussion here: https://github.com/overhangio/tutor/pull/984
This is a breaking change that will explicitely set the timeout of
course structure cache entries to 1 week, instead of being unlimited. If
you wish to revert to the former behaviour, you should set
`course_structure_cache["TIMEOUT"] = None`.
The course structure cache keys were previously set with an explicit
timeout of `None` which was overriding the cache default timeout of 2h.
This was OK in environments where the cache is configured with a maximum
memory limit and an automatic key eviction strategy. But in others (such
as Tutor), the course structure cache could grow infinitely.
It was agreed that course structure cache keys should be long-lived but
should respect the default cache structure timeout. Thus, we set here
the TTL to 1 week.
We can also configure Tutor to use a cache eviction policy. But that
means we need to set a `maxmemory` value in Redis. It's not possible to
set a value that will be appropriate for everyone:
- if it's higher than the total memory (e.g: in small instances), server
will crash before the cache is filled.
- if it's too low (e.g: in large instances), the whole platform will abruptly
slow down as many cache entries are suddenly evicted.
That question of whether Tutor should define a cache eviction policy is
still under discussion, but it can be resolved independently of this
change.
