* Add STUDENT_REGISTRATION_COMPLETED event after the user's registration
* Add SESSION_LOGIN_COMPLETED event after the user's login session
* Add COURSE_ENROLLMENT_CREATED event after the user's enrollment creation
Previously, using the bulk delete tool in the Django admin for
`CertificateDateOverride`s would not trigger the post to the credentials
service to delete the corresponding date override stored there. This was
because we were sending the COURSE_CERT_CHANGED signal from an
overridden version of the delete() method. But the Django docs warn:
"Note that the delete() method for an object is not necessarily called
when deleting objects in bulk using a QuerySet or as a result of a
cascading delete. To ensure customized delete logic gets executed, you
can use pre_delete and/or post_delete signals."
Now we use the post_delete signal instead of overriding the delete()
method to make sure the COURSE_CERT_CHANGED signal is sent for both
individual and bulk deletes.
MICROBA-1487
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>
In the PR https://github.com/edx/edx-platform/pull/10659 the outer_atomic decorator/context manager was created to prevent nested atomic blocks. This method received a boolean parameter read_committed to enforce read-committed MySQL isolation level. From Django 2, the default isolation level Django sets is read-committed, so the aforementioned parameter for outer_atomic can be removed
CookieNameChange allowed the use of the expand-contract pattern for
cookies, but the suggested procedure assumed an instantaneous change on
the server side. Without that, there would be a brief window of time where
servers that had received the newer config would be writing cookies that
the servers with old config would not be able to understand.
However, the mechanism can be made seamless by using it *twice* in
succession, with the first usage in a "no-op" configuration. This allows
all the servers to become aware of the new name without using it. The
second change flips the configuration and changes the official name of the
cookie, and during that window both sets of servers are able to understand
both sets of names, even though they're sending a mix of names. This can
then be followed by the usual cleanup.
