BREAKING CHANGES:
- `CORS_ORIGIN_WHITELIST` now requires URI schemes.
- Added new list `CORS_ORIGIN_WHITELIST_WITH_SCHEME` which contains all links of `CORS_ORIGIN_WHITELIST` with schemes and load the desired list after checking installed version.
- For more details, visit this: https://github.com/adamchainz/django-cors-headers/blob/main/HISTORY.rst#320-2019-11-15
With the PR it will load the old `CORS_ORIGIN_WHITELIST` since there is no change in `djang-cor-headers` version. In next PR this version will get upgraded.
* feat: [AA-950] Productize Streak Discount
- Change STREAK_DISCOUNT_EXPERIMENT_FLAG to STREAK_DISCOUNT_FLAG
- Remove references to "experiment" and ticket AA-759
- Made flag names more consistent
- Move segment event from get_bucket to streak calculation
- Streak discount event edx.bi.course.streak_discount_enabled is sent when celebrations are calculated
- Convert LegacyWaffleFlags to WaffleFlags
Co-authored-by: cdeery <cdeery@edx.edu>
This helper is used by the LMS, CMS, _and_ `openedx.core`,
so let's move it to `openedx.core` to reduce import complexity.
The following files no longer import from LMS:
- cms/djangoapps/contentstore/management/commands/edit_course_tabs.py
- lms/djangoapps/ccx/migrations/0006_set_display_name_as_override.py
- openedx/core/djangoapps/ccxcon/api.py
- openedx/core/djangoapps/verified_track_content/models.py
- openedx/features/course_experience/plugins.py
Note: The LTI XBlock has a dependency on this import path (!?);
a fix can be found here [1].
- [1] https://github.com/edx/xblock-lti-consumer/pull/154
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.
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.
* Generate common/djangoapps import shims for LMS
* Generate common/djangoapps import shims for Studio
* Stop appending project root to sys.path
* Stop appending common/djangoapps to sys.path
* Import from common.djangoapps.course_action_state instead of course_action_state
* Import from common.djangoapps.course_modes instead of course_modes
* Import from common.djangoapps.database_fixups instead of database_fixups
* Import from common.djangoapps.edxmako instead of edxmako
* Import from common.djangoapps.entitlements instead of entitlements
* Import from common.djangoapps.pipline_mako instead of pipeline_mako
* Import from common.djangoapps.static_replace instead of static_replace
* Import from common.djangoapps.student instead of student
* Import from common.djangoapps.terrain instead of terrain
* Import from common.djangoapps.third_party_auth instead of third_party_auth
* Import from common.djangoapps.track instead of track
* Import from common.djangoapps.util instead of util
* Import from common.djangoapps.xblock_django instead of xblock_django
* Add empty common/djangoapps/__init__.py to fix pytest collection
* Fix pylint formatting violations
* Exclude import_shims/ directory tree from linting
* Use full LMS imports paths in LMS settings and urls modules
* Use full LMS import paths in Studio settings and urls modules
* Import from lms.djangoapps.badges instead of badges
* Import from lms.djangoapps.branding instead of branding
* Import from lms.djangoapps.bulk_email instead of bulk_email
* Import from lms.djangoapps.bulk_enroll instead of bulk_enroll
* Import from lms.djangoapps.ccx instead of ccx
* Import from lms.djangoapps.course_api instead of course_api
* Import from lms.djangoapps.course_blocks instead of course_blocks
* Import from lms.djangoapps.course_wiki instead of course_wiki
* Import from lms.djangoapps.courseware instead of courseware
* Import from lms.djangoapps.dashboard instead of dashboard
* Import from lms.djangoapps.discussion import discussion
* Import from lms.djangoapps.email_marketing instead of email_marketing
* Import from lms.djangoapps.experiments instead of experiments
* Import from lms.djangoapps.gating instead of gating
* Import from lms.djangoapps.grades instead of grades
* Import from lms.djangoapps.instructor_analytics instead of instructor_analytics
* Import form lms.djangoapps.lms_xblock instead of lms_xblock
* Import from lms.djangoapps.lti_provider instead of lti_provider
* Import from lms.djangoapps.mobile_api instead of mobile_api
* Import from lms.djangoapps.rss_proxy instead of rss_proxy
* Import from lms.djangoapps.static_template_view instead of static_template_view
* Import from lms.djangoapps.survey instead of survey
* Import from lms.djangoapps.verify_student instead of verify_student
* Stop suppressing EdxPlatformDeprecatedImportWarnings
This is part of a removal of the many override methods of toggle
flag/namespace classes. This allows us to remove imports of test modules
from production code.
Specifically, pass the MFE the audit access expiration date and
let it know when the upgrade deadline has passed, by not passing
any verified mode information along.
Since code-annotations==0.7.0, incremental_release, launch_date,
monitored_rollout, graceful_degradation, beta_testing are all considered
as "temporary" use cases.
Instead of going up the stacktrace to find the module names of waffle
flags and switches, we manually pass the module __name__ whenever the
flag is created. This is similar to `logging.getLogger(__name__)`
standard behaviour.
As the waffle classes are used outside of edx-platform, we make the new
module_name argument an optional keyword argument. This will change once
we pull waffle_utils outside of edx-platform.
Note that the module name is normally only required to view the list of
existing waffle flags and switches. The module name should not be
necessary to verify if a flag is enabled. Thus, maybe it would make
sense to create a `add` class methor similar to:
class WaffleFlag:
@classmethod
def add(cls, namespace, flag, module):
instance = cls(namespace, flag)
cls._class_instances.add((instance, module))
This effectively evaluates the flag outside of the context of a course.
This was previously available through `.is_enabled_without_course_context`,
which has been removed in favor of simply `is_enabled()`.
This was done to make the CourseWaffleFlag interface more uniform with
that of WaffleFlag and ExperimentWaffleFlag and eliminate unecessary
branching when handling CourseWaffleFlags.
For the Courseware MFE rollout experiment, we want users'
default buckets to be consistent across course runs.
ExperimentWaffleFlag advised that this could be done
by calling `.is_enabled(...)` without a course_key argument;
however, doing so breaks when uing the main_flag.BUCKET_NUM
scheme to apply bucket rules for a specific set of users
or courses.
This commit explicitly adds course-unaware-bucketing via
a new kwarg to ExperimentWaffleFlag.__init__ method.
Furthermore, it fixes ExperimentWaffleFlag.is_enabled(course_key=None)
to work as advertised, by means of calling
.is_enabled_without_course_context on its subordinate flags.
TNL-7405
Create a Javascript function to log upsell events to & attach the eventing to the course dashboard upsell button. The revenue squad is looking for more insight into which buttons users are clicking to get to the checkout page.
- Looks at masquerading config for dates, outline, metadata, and
celebration APIs in course_home_api / courseware_api.
- Consolidates and cleans up places we check whether masquerading
gives us full access to a course.
- Add a new CourseEnrollmentCelebration model, which ties a
course enrollment to some booleans about progress celebrations
- Add serialization of the new model to the existing courseware_api
app's existing course info view
- Add new API in courseware_api to update a celebration model
I wanted to make a byte-sized contribution but there were no Jira tickets so we decided, thanks to a conversation with @jmbowman through the Open Edx Community #incr (Slack) channel, to collaborate in the elimination of warnings listed in the Warnings Report at https://build.testeng.edx.org/job/edx-platform-python-pipeline-master/warning_5freport_5fall_2ehtml/
This PR contributes to the elimination of deprecation warnings, specifically the one mentioned above and reported in the Warnings Report.
Changed logger.warn to logger.warning in the following files:
lms/djangoapps/experiments/utils.py
lms/djangoapps/lti_provider/outcomes.py
lms/djangoapps/courseware/module_render.py
This warning occurs due to deprecation in python 3.4+: https://docs.python.org/3.5/library/logging.html#logging.Logger.warning
