This commits prepares edx-platform's experimental Dockerfile
for optional use in devstack. Presently, the image built by this
Dockerfile isn't used anywhere.
Notable changes:
* Drop the openedx/edx-platform image name in favor of
openedx/lms and openedx/cms.
* Drop the newrelic stages and tags.
* Create openedx/lms-dev and openedx/cms-dev image
variants which use Django devserver, install dev
requirements, and specify devstack Django settings.
* Add config files at (lms,cms)/envs/devstack-experimental.yml,
extracted from the existing edxapp docker image.
* Adds three new scripts, each of which replaces an Ansible
or Paver-supported function with a pure bash + Django
management command implementation.
Formerly, the 'courseware.courseware_mfe' Waffle flag was
required in order use the new Learning-MFE-based courseware
frontend. However, the Learning-MFE-based frontend has since
become the default, with the 'courseware.use_legacy_frontend'
flag instead serving as an opt-out.
The LEARNING_MICROFRONTEND_URL Django setting annotation
erroneously still referenced the old 'courseware.courseware_mfe'
flag. This commit removes the outdated reference.
User Tours are walkthroughs we are able to give in our frontends.
This sets up the backend support for them by creating the model,
setting up the initial backfill, adds in a signal handler to init
the UserTour model on User creation, and sets up some endpoints
to get user tour information and update it. It is also being
initialized with a waffle flag to control the rollout. The flag is
intended to control all tours and not allow for opting into only some tours.
* refactor: deprecates ModuleSystem.render_template
in favor of the added MakoSystem render_template method.
Related changes:
* Adds the MakoService to the StudioEditModuleRuntime,
PreviewModuleSystem, LmsModuleSystem, and XBlockRuntime
* MakoService constructor takes a `namespace_prefix` string, so that the
CMS PreviewModuleSystem can render to LMS templates, without needing
the special render_from_lms helper method.
* ModuleSystem.render_template becomes a read-only property, so the
constructor calls and test module systems are updated accordingly.
* Adds tests for the MakoService and module system shims.
(cherry picked from commit 457f959356)
* refactor: use MakoService.render_template to remove deprecation warnings
from block code.
(cherry picked from commit 8d62d337f5)
* refactor: use MakoService.render_template to remove deprecation warnings
from test code.
(cherry picked from commit 26b43465a4)
* test: Adds a test to verify the bug introduced by the previous changes
The AuthoringMixin is automatically added to all XBlocks (see
settings.XBLOCK_MIXINS), and AuthoringMixin.visibility_view expects the
"mako" service.
This test verifies the bug by testing the PureXBlock, which does not
require the "mako" service, and so fails when the visibility_view is
rendered.
* fix: AuthoringMixin needs mako service
which fixes the visibility_view for XBlocks which don't explicitly
require the mako service.
Also removes the unneeded class property _services_requested from
AuthoringMixin and StudioEditableBlock. This property is better provided
by the XBlockMixin class.
* feat: Add support for using the discussions MFE UI instead of existing UI
Adds a new course waffle flag that when set along with the discussions MFE URL shows the discussions MFE UI instead of the regular UI.
* test: add tests
* squash!: more consistent url name
* chore: update deprecated import from collections
* chore: remove outdated imports from markdown library
as it hasn't been supported since 2.0.3 and we're on 3.x.
This was deprecated at least as early as 2012!
* docs: add docstring and remove lint-amnesty to markdown plugin
* chore: remove deprecated etree import
* style: remove unnecessary-comprehension for sets
* style: resolve a number of amnestied pylint complaints
Co-authored-by: stvn <stvn@mit.edu>
in favor of the added MakoSystem render_template method.
Related changes:
* Adds the MakoService to the StudioEditModuleRuntime,
PreviewModuleSystem, LmsModuleSystem, and XBlockRuntime
* MakoService constructor takes a `namespace_prefix` string, so that the
CMS PreviewModuleSystem can render to LMS templates, without needing
the special render_from_lms helper method.
* ModuleSystem.render_template becomes a read-only property, so the
constructor calls and test module systems are updated accordingly.
* Adds tests for the MakoService and module system shims.
[MICROBA-1569]
- filter bulk course email recipients based on the last_login date of a learner's user account
- introduces a new setting named `BULK_COURSE_EMAIL_LAST_LOGIN_ELIGIBILITY_PERIOD` that sets the login threshold to be included (in months) to a bulk course email message(if set)
* feat: degreed2 integrated channels
ENT-2789
* feat: ✨ New integrated channel via edx-enterprise
* fix: pull in edx-enterprise 3.33.1
fixes db_overrides check failure by renaming field `key` to `client_id`
The VERIFIED_NAME_FLAG, the VerifiedNameEnabledView, and the verified_name_enabled key removed from responses for both VerifiedNameView view and VerifiedNameHistoryView
were removed as part https://github.com/edx/edx-name-affirmation/pull/12. This was released in version 2.0.0 of the edx-name-affirmation PyPI package. Please see below for additional context for the removal, copied from the name-affirmation commit message.
The VERIFIED_NAME_FLAG was added as part https://github.com/edx/edx-name-affirmation/pull/12, [MST-801](https://openedx.atlassian.net/browse/MST-801) in order to control the release of the Verified Name project. It was used for a phased roll out by percentage of users.
The release reached a percentage of 50% before it was observed that, due to the way percentage roll out works in django-waffle, the code to create or update VerifiedName records was not working properly. The code was written such that any change to a SoftwareSecurePhotoVerification model instance sent a signal, which was received and handled by the Name Affirmation application. If the VERIFIED_NAME_FLAG was on for the requesting user, a Celery task was launched from the Name Affirmation application to perform the creation of or update to the appropriate VerifiedName model instances based on the verify_student application signal. However, we observed that when SoftwareSecurePhotoVerification records were moved into the "created" or "ready" status, a Celery task in Name Affirmation was created, but when SoftwareSecurePhotoVerification records were moved into the "submitted" status, the corresponding Celery task in Name Affirmation was not created. This caused VerifiedName records to stay in the "pending" state.
The django-waffle waffle flag used by the edx-toggle library implements percentage rollout by setting a cookie in a learner's browser session to assign them to the enabled or disabled group.
It turns out that the code that submits a SoftwareSecurePhotoVerification record, which moves it into the "submitted" state, happens as part of a Celery task in the verify_student application in the edx-platform. Therefore, we believe that because there is no request object in a Celery task, the edx-toggle code is defaulting to the case where there is no request object. In this case, the code checks whether the flag is enabled for everyone when determining whether the flag is enabled. Because of the percentage rollout (i.e. waffle flag not enabled for everyone), the Celery task in Name Affirmation is not created. This behavior was confirmed by logging added as part of https://github.com/edx/edx-name-affirmation/pull/62.
We have determined that we do not need the waffle flag, as we are comfortable that enabling the waffle flag for everyone will fix the issue and are comfortable releasing the feature to all users. For this reason, we are removing references to the flag.
[MST-1130](https://openedx.atlassian.net/browse/MST-1130)
This is so that the lms default celery queue does not get backed up
when coursegraph is hosed (which is likely when coursegraph has been
redeployed and needs to get the full set of courses).
TNL-8386
Split modulestore persists data in three MongoDB "collections": course_index (list of courses and the current version of each), structure (outline of the courses, and some XBlock fields), and definition (other XBlock fields). While "structure" and "definition" data can get very large, which is one of the reasons MongoDB was chosen for modulestore, the course index data is very small.
This commit starts writing course indexes (active_versions) to both MySQL and Mongo, but continues to read from MongoDB only.
By moving course index data to MySQL / a django model, we get these advantages:
* Full history of changes to the course index data is now preserved
* Includes a django admin view to inspect the list of courses and libraries
* It's much easier to "reset" a corrupted course to a known working state, by using the simple-history revert tools from the django admin.
* The remaining MongoDB collections (structure and definition) are essentially just used as key-value stores of large JSON data structures. This paves the way for future changes that allow migrating courses one at a time from MongoDB to S3, and thus eliminating any use of MongoDB by split modulestore, simplifying the stack.
Split modulestore persists data in three MongoDB "collections": course_index (list of courses and the current version of each), structure (outline of the courses, and some XBlock fields), and definition (other XBlock fields). While "structure" and "definition" data can get very large, which is one of the reasons MongoDB was chosen for modulestore, the course index data is very small.
By moving course index data to MySQL / a django model, we get these advantages:
* Full history of changes to the course index data is now preserved
* Includes a django admin view to inspect the list of courses and libraries
* It's much easier to "reset" a corrupted course to a known working state, by using the simple-history revert tools from the django admin.
* The remaining MongoDB collections (structure and definition) are essentially just used as key-value stores of large JSON data structures. This paves the way for future changes that allow migrating courses one at a time from MongoDB to S3, and thus eliminating any use of MongoDB by split modulestore, simplifying the stack.
- Fixed LANGUAGE_COOKIE settings name to LANGUAGE_COOKIE_NAME beacuse later is recognised by django
- Added test to verify cookies use in dark lang middleware
- Fixing Django 3.0 tests
This was causing issue with Django 3.2, as Django has restricted to only use language from the pre-defined set of languages provided by Django.
BOM-2870
which can be configured from the lms/studio environment
refactor: raise ImproperlyConfigured on TypeError
Signed-off-by: Gabor Boros <gabor.brs@gmail.com>
Co-authored-by: Jillian Vogel <jill@opencraft.com>
