* Add COURSE_ENROLLMENT_CHANGED: sent after the enrollment update
* Add COURSE_UNENROLLMENT_COMPLETED: sent after the user's unenrollment
* Add CERTIFICATE_CREATED after the user's certificate generation has
been completed
* Add CERTIFICATE_CHANGED: after the certification update has been
completed
* Add CERTIFICATE_REVOKED: after the certificate revocation has been
completed
* Add COHORT_MEMBERSHIP_CHANGED: when a cohort membership update ends
If the bundle is deleted, `blockstore_cache.get_bundle_version_number(bundle_uuid)`
will raise an error.
Catch this error in `get_bundle_links`,
so the REST api doesn't crash with a 500 error when a linked bundle is deleted.
MST-970. If name affirmation is enabled, a user should only be allowed to make limited edits to their profile name before they are required to go through IDV. Right now, the allowable edits are limited to:
* add/delete/replace one character (including one space on either side)
Edits that are not allowed, and therefore require IDV include:
* changing 2 or more characters
* changing their name 3 or more times
This behavior will not be enabled until name affirmation is fully rolled out, so there should be no noticeable difference in account settings behavior at the time this is merged.
Now that we're actively using the LMS_USER_ID inside credentials to
identify users, we need to make sure that users created by
notify_credentials are including it in the jwt scopes when authenticated
with credentials.
* feat: adding monitoring to CookieNameChange middleware
Adding custom attribute: cookie.change_name
if cookie.change_name in transaction and equal 0, cookie with alternate name is detected and deleted
if cookie.change_name in transaction and equal 1, cookie with current name not in request and added
When first building the Certificate Date Override feature, I set up the
CertificateDateOverride model to store the override dates as Dates
instead of DateTimes.
Turns out this is not how edX typically handles dates, and it’s causing
some minor headaches around needing to convert values. Also, using just
Dates causes timezone issues.
MICROBA-1488
This changes the "Sign out" link on Studio to point to Studio's own logout
view, which clears the session and then redirects to LMS's logout page. The
LMS logout page then skips loading the Studio logout because it is seen in
the Referer header.
This change also brings Studio better into line with how other IDAs perform
their logouts.
Background:
After the rollout of Studio OAuth, logouts initiated on Studio failed to
actually log out Studio (but all other IDAs were logged out). This was
because the LMS logout view loads the logout pages of other IDAs but skips
any that is a *prefix* match on the Referer header, and browsers now often
send a truncated version of the Referer for privacy. Therefore, Studio was
always skipped when coming from Studio.
The fix is to make sure that Studio has already performed its logout by the
time the LMS logout page is loaded.
One wrinkle here is that the LMS logout view is activated by `/logout`, but
the correct logout view (provided by auth_backends) is activated by
`/logout/` -- with a trailing slash. This is fragile and unfortunate, but
can be cleaned up when we later remove other leftovers of Studio's previous
ability to handle logistration.
ref: ARCHBOM-1897
We use the `notify_credentials` management command to keep certificate-
related data in the LMS and Credentials service in sync. We can run it
with specific arguments (user_ids, course_keys, etc.) when we notice a
data discrepancy; and it is run regularly by a Jenkins job with the
`--auto` flag every ~4 hours to keep things up-to-date.
Because we probably never want to notify credentials of of ALL the
GeneratedCertificates, the celery task must be given some arguments
to filter down to the relevant certificates. Running the management
command with the `--auto` flag (as the Jenkins job does) adds
`start_date` and `end_date` arguments of 4 hours ago and now,
respectively.
The handle_notify_credentials celery task then takes those arguments and
looks for any GeneratedCertificates that have been modified within the
given time range by checking the GeneratedCertificate modified_date.
It will send the current data for those certificates to credentials.
However, we also want to notify credentials about certificates that have
an associated CertificateDateOverride that has changed within that time
range: added, updated, or deleted. But changes to a
CertificateDateOverride won’t affect the GeneratedCertificate’s modified
date, and therefore wouldn’t be included in the list of certs cent to
credentials.
This commit adds a check for changed CertificateDateOverrides and
includes their associated GeneratedCertificates in the list of certs. We
use the CertificateDateOverride’s history model for this check so that
we can include certificates whose override was deleted.
MICROBA-1489
Currently, if a learner manually loads a sequence page that would
normally be skipped for them because it is hidden-after-due, the
sequence renders anyway.
This commit tells the frontend when it should not show a sequence
because it's hidden.
AA-1000
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
Reverting because of errors seen in proctoring. The error from splunk:
File "/edx/app/edxapp/venvs/edxapp/lib/python3.8/site-packages/edx_proctoring/views.py", line 590, in get
data['onboarding_release_date'] = effective_start.isoformat()
AttributeError: 'NoneType' object has no attribute 'isoformat'
The effective date is coming from learning_sequences, which ultimately
comes from edx-when.
* feat!: Add data model for course app API
The current course apps API makes individual queries to determine if a course app is enabled, which can be inefficient. With this change we now have a Django model that contains this information, allowing us to make bulk queries about all the course apps for a course in the API.
It also adds a new signal handler that initialises the status of all course apps in a course on course publish.
* Use celery tasks and a management commands to make cache async
* Review feedback
* update log messages
use separate celery task for each course task
* fix: [AA-950] Add unit test to verify segment called correctly
Add positive and negative test
Moved flag update to same block as segment
Moved WaffleFlag check to can_show_streak_discount_coupon for consistency
course outline, which don't need block dates below the subsection level of a course.
Pass the course's published version to all the appropriate places where edx-when's API
is called - to allow edx-when to more efficiently cache queried/processed results.
TNL-8061
* 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
* 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.
