* refactor(certificates): replace direct model imports with data classes and APIs
* fix: use Certificates API to create certificates
* docs: update docstring for get_certificate_for_user
* fix: remove trailing whitespace
---------
Co-authored-by: coder1918 <ram.chandra@wgu.edu>
Co-authored-by: Deborah Kaplan <deborahgu@users.noreply.github.com>
There is a singleton SplitMongoModuleStore instance that is returned
whenever we call the ubiquitous modulestore() function (wrapped in a
MixedModuleStore). During initialization, SplitMongoModuleStore sets
up a small handful of XBlock runtime services that are intended to be
shared globally: i18n, fs, cache.
When we get an individual block back from the store using get_item(),
SplitMongoModuleStore creates a SplitModuleStoreRuntime using
SplitMongoModuleStore.create_runtime(). These runtimes are intended to
be modified on a per-item, and later per-user basis (using
prepare_runtime_for_user()).
Prior to this commit, the create_runtime() method was assigning the
globally shared SplitMongoModuleStore.services dict directly to the
newly instantiated SplitModuleStoreRuntime. This meant that even though
each block had its own _services dict, they were all in fact pointing
to the same underlying object. This exposed us to a risk of multiple
threads contaminating each other's SplitModuleStoreRuntime services
when deployed under load in multithreaded mode. We believe this led to
a race condition that caused student submissions to be mis-scored in
some cases.
This commit makes a copy of the SplitMongoModuleStore.services dict for
each SplitModuleStoreRuntime. The baseline global services are still
shared, but other per-item and per-user services are now better
isolated from each other.
This commit also includes a small modification to the PartitionService,
which up until this point had relied on the (incorrect) shared instance
behavior. The details are provided in the comments in the
PartitionService __init__().
It's worth noting that the historical rationale for having a singleton
ModuleStore instance is that the ModuleStore used to be extremely
expensive to initialize. This was because at one point, the init
process required reading entire XML-based courses into memory, or
pre-computing complex field inheritance caches. This is no longer the
case, and SplitMongoModuleStore initialization is in the 1-2 ms range,
with most of that being for PyMongo's connection setup. We should try
to fully remove the global singleton in the Verawood release cycle in
order to make this kind of bug less likely.
refactor: move editor_saved to VideoConfigService (#37829)
* This moves edx-platform-specific logic out of the VideoBlock,
in preparation for the VideoBlock extraction
Removes temporary rollout toggle ENABLE_SAML_CONFIG_SIGNAL_HANDLERS. The
toggle was used to rollout a fix, and now the fix that uses the signal handlers is
enabled by default.
The only follow-up needed by anyone is to no longer set this toggle, which will no
longer do anything.
This is to fix an issue in the following common migration situation:
1. An existing course references content in a legacy content library.
2. The legacy content library is migrated to the new library system.
3. The user clicks on "Update reference" from the Randomized Content
Block in the course.
This action is supposed to update the children of the
LibraryContentBlock (usually ProblemBlocks) so that the "upstream"
attribute is set to point at the UsageKeys of the content in the new
libraries they were migrated to. What was happening instead was that the
upstream entries for these child blocks were left blank, breaking the
upstream/sync connection and making it so that the courses did not
receive any updates from the migrated libraries.
There were two issues:
1. get_forwarding_for_blocks() was being called with the child UsageKeys
in the course, when it should have been called with the v1 library
usage keys instead (since those are the things being forwarded).
2. We were checking that the target_key was a v2 Library key, but really
the upstream target_key is supposed to be a LibraryUsageLocatorV2,
i.e. the key of the specific piece of content, not the library it
ended up in.
Note on testing:
Although there were unit tests for the migration of legacy content
libraries, there were not any unit tests for the migration of legacy
library *blocks*.
This commit adds a minimal test, which would have caught the bug we're
fixing. It would be good to add more comprehensive testing unit testing
for this part of the migration flow.
---------
Co-authored-by: Kyle McCormick <kyle@axim.org>
For some reason sphinx is being listed as a thing that requires
`roman-numerals` during the upgrade call but not during
`compile-requirements`. This just commits the expectations from
compile-requirements for now so we can land the package update.
Adds API to fetch all legacy library content blocks that are ready to be updated to use library v2 and convert to item banks.
Also adds API to update all the references via a user celery task and to fetch its status.
Re-compilation and upgrade-package should be able to run without
updating the common_constraints.txt file. We do this all the time when
backporting fixes to older releases. We shouldn't pull in the latest
common_constraints.txt in those cases as they may not be compatible with
older releases.
Prior to this, if ENABLE_ORGANIZATION_STAFF_ACCESS_FOR_CONTENT_LIBRARIES
was enabled, we would not return the orgs that someone had course
creator rights on, even if ENABLE_CREATOR_GROUP was enabled. (For the
moment, we are conflating "can create courses" with "can create
libraries" for a given org, even though we should probably eventually
split those apart.)
For legacy library_content references in courses, this PR:
- **Removes the spurious sync after updating a reference to a migrated
library**, so that users don't need to "update" their content _after_
updating their reference, _unless_ there were real content edits that
happened since they last synced. We do this by correctly associating a
DraftChangeLogRecord with the ModulestoreBlockSource migration artifact,
and then comparing that version information before offering a sync.
(related issue:
https://github.com/openedx/frontend-app-authoring/issues/2626).
- **Prompts users to update a reference to a migrated library with higher
priority than prompting them to sync legacy content updates for that
reference**, so that users don't end up needing to accept legacy content
updates in order to get a to a point where they can update to V2 content.
- **Ensures the library references in courses always follow the correct
migration,** as defined by the data `forwarded` fields in the data model,
which are populated based on the REST API spec and the stated product UI
requirements.
* For the migration itself, this PR:
- **Allows non-admins to migrate libraries**, fixing:
https://github.com/openedx/edx-platform/issues/37774
- **When triggered via the UI, ensures the migration uses nice title-based
target slugs instead of ugly source-hash-based slugs.** We've had this as an
option for a long time, but preserve_url_slugs defaulted to True instead of
False in the REST API serializer, so we weren't taking advantage of it.
- **Unifies logic between single-source and bulk migration**. These were
implement as two separate code paths, with drift in their implementations. In
particular, the collection update-vs-create-new logic was completely
different for single-souce vs. bulk.
- **When using the Skip or Update strategies for repeats, it consistently
follows mappings established by the latest successful migration** rather than
following mappings across arbitrary previous migrations.
- **We log unexpected exceptions more often**, although there is so much more
room for improvement here.
- **Adds more validation to the REST API** so that client mistakes more often
become 400s with validation messages rather than 500s.
For developers, this PR:
- Adds unit tests to the REST API
- Ensures that all migration business logic now goes through a general-purpose
Python API.
- Ensures that the data model (specifically `forwarded`, and
`change_log_record`) is now populated and respected.
- Adds more type annotations.
We haven't done anything specila for lms-xml for over a decade and we
dropped lms-preview support last year when we added preview capabality
to the new Authoring MFE.
https://github.com/openedx/edx-platform/pull/36460
