Specifically, send data versions of course_expired_message and
offer_html.
The rendered HTML is still being sent for now, until the learning
MFE is updated to consume the data objects.
This change was reverted along with the downgrade of super-csv because
it was believed that this change was causing issues with celery task
registration.
It was reverted in https://github.com/edx/edx-platform/pull/25762
The fix turned out to be something different and this and the
super-csv library should both be same to upgrade. The library
upgrade will come in a follow-on make upgrade with some other
constraints that also need to be lifted.
Actual fix: https://github.com/edx/edx-platform/pull/25822
The toggle was previously an ExperimentWaffleFlag,
which allows stable A/B testing but increases the toggle's
complexity. Since we do not plan an doing any more A/B
tests as part of the MFE rollout, we can 'downgrade' this
toggle to a CourseWaffleFlag, which still allows us to do
phased rollout and course-run-specific overrides.
Adds can_show_course_sock and verified_mode values to the outline
API serialization. And adds a utility method to generate the
verified_mode dictionary, shared with the courseware API.
Waffle classes no longer have namespaces. All features are moved to the
WaffleFlag/WaffleSwitch classes.
Here we use the edx_toggles.toggles.__future__ API, which is available
in 1.2.0. This means that we don't have to upgrade edx-toggles. We
should remove the __future__ imports as soon as we upgrade to 2.0.0.
This is required because edx-platform uses the waffle API from
completion, which itself depends on edx-toggles. So if we change
edx-toggles import paths, we also need to upgrade our usage of
completion here.
By explicitly importing the legacy namespace classes, we make it clear
that we are using soon-to-be-deprecated classes. We will then be able to
start removing the legacy classes, one module at a time.
* Install `organizations` app into LMS and Studio non-optionally.
* Add toggle `ORGANIZATIONS_AUTOCREATE` to Studio.
* Remove the `FEATURES["ORGANIZATIONS_APP"]` toggle.
* Use the new `organizations.api.ensure_organization` function to
either validate or get-or-create organizations, depending
on the value of `ORGANIZATIONS_AUTOCREATE`,
when creating course runs and V2 content libraries.
We'll soon use it for V1 content libraries as well.
* Remove the `util.organizations_helpers` wrapper layer
that had to exist because `organizations` was an optional app.
* Add `.get_library_keys()` method to the Split modulestore.
* Add Studio management command for backfilling organizations tables
(`backfill_orgs_and_org_courses`).
For full details, see
https://github.com/edx/edx-organizations/blob/master/docs/decisions/0001-phase-in-db-backed-organizations-to-all.rst
TNL-7646
DEPR-43 - Removal of Shoppingcart.
All models have been removed and the change has been deployed to production
so this should be safe to do.
It's strange that the ORM decided to drop certain fields before dropping the
whole models but decided to leave it all as the ORM generated it rather than
trying to manually change it.
Also turn the check back on to make sure people don't actually check in code
without the relevant migration files.
* MST-542 remove the IDV redirect to Account MFE waffle flag to permanently redirect learners to new IDV workflow. This completes the rollout process on edx-platform
Technically, both "2020-10-20T23:59:00Z" and "2020-10-20T23:59:00+00:00"
are ISO-8601 compliant, though the latter is preferred. The Discussions
API uses the "Z" notation for almost all its dates, except for the
course blackout dates (those times when students aren't allowed to post
anything because it would threaten exam integrity). That's because the
blackout dates are manually formatted using datetime.isoformat().
As best as I can tell, we've always passed back the "+00:00" for the
blackout dates. But at some point, this broke the expectations of the
mobile apps, which expect the "+Z" format, like the rest of the API.
This commit changes the blackout dates to be returned in +Z format when
the blackout datetimes are specified by the user in UTC (which is almost
always the case–I suspect the mobile clients would break if the dates
were specified in other timezones anyhow).
