This commit removes several waffle toggles that have been enabled
on edx.org for years. It's time to remove the rollout gating for
these features and enable them by default.
This doesn't directly change any behavior. But it does create new
database objects by default now and allows for enabling other
schedule based features more easily.
Specifically, the following toggles were affected.
schedules.create_schedules_for_course
- Waffle flag removed as always-enabled
- We now always create a schedule when an enrollment is created
schedules.send_updates_for_course
- Waffle flag removed as always-enabled
- Course update emails are sent as long as the ScheduleConfig
allows it.
- This is not a change in default behavior, because ScheduleConfig
is off by default.
dynamic_pacing.studio_course_update
- Waffle switch removed as always-enabled
- Course teams can now always edit course updates directly in Studio
ScheduleConfig.create_schedules
ScheduleConfig.hold_back_ratio
- Model fields for rolling out the schedules feature
- Schedules are now always created
- This commit only removes references to these fields, they still
exist in the database. A future commit will remove them entirely
This commit also adds a new has_highlights field to CourseOverview.
This is used to cache whether a course has highlights, used to
decide which course update email behavior they get. Previously every
enrollment had to dig into the modulestore to determine that.
This feature uses the first_day_of_streak, last_day_of_streak and last_streak_celebration fields to determine whether the user should see a celebration.
AA-304
Now that we always return an existing value from the DB rather than trusting that ID generation is deterministic and constant over time, we're free to change the generation algorithm.
Our long term goal is to switch to random IDs, but we need to first investigate the uses of save=False. In the meantime, this is a good opportunity to move away from MD5, which has a number of cryptographic weaknesses. None of the known vulnerabilities are considered exploitable in this location, given the limited ability to control the input to the hash, but we should generally be moving away from it everywhere for consistency.
This change should not be breaking even for save=False callers, since those calls are extremely rare (1 in 100,000) and should only occur after a save=True call, at which point they'll use the stored value. Even if this were not true, for a save=False/True pair of calls to result in a mismatch in output, the first of the calls would have to occur around the time of the deploy of this code.
Co-authored-by: Tim McCormack <tmccormack@edx.org>
Co-authored-by: Tim McCormack <tmccormack@edx.org>
This deprecates `save=False` for several functions and removes all known
usages of the parameter but does not actually remove the parameter.
Instead, it will emit a deprecation warning if the parameter is used.
We can remove the parameter as soon as we feel sure nothing is using it.
Now that we have refactored `anonymous_id_for_user` to always prefer
retrieving an existing ID from the database -- and observed that only a
small fraction of calls pass save=False -- we can stop respecting
save=False. This opens the door for future improvements, such as generating
random IDs or switching to the external user ID system.
Metrics: I observe that 1 in 16 requests for new, non-request-cached
anon user IDs are made with save=False. But 71% of all calls are served
from the request cache, and 99.7% of the misses are served from the DB.
save=False only appear to come from intermittent spikes as reports are
generated and are low in absolute number.
Also document usage/risk/rotation of secret in anonymous user ID
generation as indicated by `docs/decisions/0008-secret-key-usage.rst`
ADR on `SECRET_KEY` usage.
ref: ARCHBOM-1683
In commit 2723e0e2/PR #26162, we created a new version of the
`anonymous_id_for_user` method that would make it safe to rotate the
`SECRET_KEY` setting (without changing existing anonymous IDs). This
included a toggle to allow fast reversion to the old code if needed.
This commit removes the old code and the toggle as we are satisfied with
the correctness and performance of the new code.
ref: ARCHBOM-1645
The old name was
`student.send_activation_email`.
The new name is now
`common.djangoapps.student.tasks.send_activation_email`.
We no longer user the old task name,
so we can safely stop registering it with Celery
workers, without fear of dropping any lingering
tasks under the old name.
The old name is
`student.send_activation_email`.
The new name is
`common.djangoapps.student.tasks.send_activation_email`.
We currently register both the old and the new task names,
such that Celery workers recognize the task by both names.
This commit switches us from the old name to the new name.
Several tasks are explicitly named as (or like)
their old, deprecated import path.
The issue here is that django-user-tasks listens for task
invocations, and attempts to import the task based on its name.
If the task name is completely wrong, user-tasks will catch
the ImportError and move on.
If the task is a valid *deprecated* import, though, then
user-tasks will choke on the raised `DeprecatedEdxPlatformImportError`.
Thus, we must rename three tasks to their new full path:
1. entitlements.expire_old_enrollments
2. third_party_auth.fetch_saml_metadata
3. student.send_activation_email
The first two are run daily, and so are safe to be
renamed in place.
The third task must be renamed using an expand-contract
pattern; otherwise, we would drop hundreds of tasks
during the App vs. Worker out-of-sync version window
that happens at deployments.
This commit is the expand phase.
- Use different attribute names for new and old versions of function
- Use a shorter name overall (for ease of analysis)
- Add monitor for fetched-existing case
- Only record computed-stored if `get_or_create` succeeds, but also
break it into created vs. fetched cases by checking return value
- Correct name of monitor in `except` clause -- that should only happen
for a race inside `get_or_create` itself. There's a different race in
the `anonymous_uid_for_user` between fetch and compute/save.
- Other name tweaks
ARCHBOM-1674
* import task decorator from celery APP instance instead of celery package in CMS
* replaced task decorator with shared_task in cms and common
* Fixed import of shared_task
* Fixed import
These changes were initially made to make it easier to do SECRET_KEY rotations. Along the way, we found it made sense to refractor the code as well.
Changes made:
- changed get_to_create to create because now the code should only get to this block when a write is necessary
- added a lookup for anonymous_user_id. This is to return an existing anonymous_user_id rather than calculating. This will mitigate the results of SECRET_KEY rotation.
- Added monitoring to help us make better decisions: should we not sue SECRET_KEY, performance considerations...
- put old function behind toggle in case something goes wrong in production with new code
- refractoring function structure for better understanding
This addresses a longstanding TODO item to make runtime.anonymous_student_id for content libraries v2 work the same way as it does for XBlocks in regular courses, persisting the "context ID" (equivalent to course ID) to the database. This way, if SECRET KEY is changed, existing anonymous IDs will continue to work unchanged.
This is a potentially breaking change, but should mostly affect capa problems using external code graders or Matlab code input, and I'm not aware of any such usage of the new runtime / libraries v2.
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.
