Does 3 things:
(1) Use django for modulestore tests
(2) Use normal LMS settings for modulestore tests instead of openedx/tests/settings.py
(3) Simplify some TestCase subclasses by converting them to use ModuleStoreTestCase
Details and rationale:
(1) Currently parts of the modulestore test suite are designed to run "without django", although there is still a lot of django functionality imported at times, and many of the tests do in fact use django. But for the upcoming PR #27565 (moving split's course indexes from MongoDB to MySQL), we will need to always have Django enabled. So this commit paves the way for that change.
(2) The previous tests that did use Django used a special settings file, openedx/tests/settings.py which made some debugging confusing because those tests had quite different django settings than other tests. This change deletes that file and runs the tests using the LMS test settings.
(3) The test suite also contains many different ways of initializing and testing a modulestore, with significant differences in their configuration, and also a lot of repetition. I find this makes understanding, debugging and writing tests more difficult. So this commit also reduces the number of different "test case using modulestore" base classes:
* Simplifies MixedWithOptionsTestCase and MixedSplitTestCase by making them simple subclasses of ModuleStoreTestCase.
* Removes PureModulestoreTestCase.
Some actions in split modulestore record the user ID who requested the action. Currently, split modulestore doesn't care what data type you use for those user IDs. Most of the codebase uses integers, but some tests used username or email address strings.
My upcoming PR #27565 will move split modulestore's "course index" data from MongoDB into MySQL. In doing so, it requires that user IDs are always numeric. So this PR paves the way for that one by using numeric IDs consistently in all test cases. I believe the actual non-test code was already consistently using integer IDs.
We add 'courserun_key' (aka "course_id" though that's technically a
misnomer) as an optional parameter to the /event endpoint url. If it
is not present, it will still be parsed out of the url, if the url is
of the right format.
Additionally, Logger.log() in js adds this parameter to its /event
call, pulling it from the $$course_id global.
This provides opportunity for MFEs to (separately) provide the key
without concern about url parsing.
TNL-7752
Register the new CertificateDateOverride model with the Django admin.
Customize the `generated_certificate` field to accept the certificate id
(with search); and autosave the admin user making the change to the
`overridden_by` field, and make it read-only.
For MICROBA-1417, toward MICROBA-1239.
[MICROBA-1354]
* Update Python API function named `cert_generated_enabled` to `has_self_generated_certificates_enabled` to more accurately reflect the purpose of the function
Instead of hard-coding the "Learn More" and potentially other links for course
apps in the course authoring MFEs this change loads those URLs from the
django settings as part of each individual course app.
If a content library xblock does not specify a library id, we
previously would error out when importing, due to some cleanup
code that wasn't accounting for this case.
Sanitizes Markdown that goes back and forth between the server and
client side, to strip out data: links, so that they cannot be abused.
There is no present vulnerability to this issue–modern browsers disallow
data links in the first place, and we already filter this out in both
client-side code as well as the HTML generated in the REST API (it's run
through bleach). But we're adding this anyway, to further reduce the
odds that some client-side mistake could cause a vulnerability. This is
part of TNL-8589.
Remove the option to masquerade as a generic learner
if there are enrollment tracks or partition groups
because the behavior is unpredictable and unhelpful.
Fixes: AA-893
Some providers need special considerations when being set up so should only be
configured by people with global staff privileges. This adds an
admin_only_config flag to such providers (only YellowDig for now).
