* feat: linting before touching all these files
All these files are old enough, relative either to our current linting
rules or our current linter automation, that modifying anything in them
either makes the linter cranky or wants to reformat the entire file.
Rather than mixing cleanup with code changes, this commit just lints
this set of files to our current standards.
[APER-3241]
This PR updates the retirement pipeline to purge learners' names from certificate records when their account is being retired.
It also introduces a new management command that can be used by Open edX operators to purge the leftover name data (PII data) from the `certificates_generatedcertificate` table. This is designed as a one-time use data fixup, as the retirement functionality should clean this moving forward.
* feat: receiver for invalidate certificate
- consumes event of exam attempt rejected
- initial commit, need to make tests
* temp: moving consumer from signals to handlers.py
- Still need to make this work
- Need to make tests work too
* feat: refactored underlying code to api.py
- tests still need to be tweaked
* fix: commit history
* fix: improve api func name + add source param
This PR adds the ability for the LMS to publish `CERTIFICATE_REVOKED` events to the Event Bus. There is also work in progress for Credentials to consume these events.
[APER-2347]
This PR updates the name of the topic we are publishing our `CERTIFICATE_CREATED` events to. We had put a very generic name when writing the publishing code (and this was way before the actual topic was created). Now that the Confluent configuration is ready we need to update the name in our publishing code.
[APER-2344]
We would like to start consuming Certificate related events in Credentials from the event bus. This PR starts the process by publishing CERTIFICATE_CREATED events to the event bus. It also introduces a new feature flag (`SEND_CERTIFICATE_CREATED_SIGNAL`) to gate the functionality.
It's long past time that the default test modulestore was Split,
instead of Old Mongo. This commit switches the default store and
fixes some tests that now fail:
- Tests that didn't expect MFE to be enabled (because we don't
enable MFE for Old Mongo) - opt out of MFE for those
- Tests that hardcoded old key string formats
- Lots of other random little differences
In many places, I didn't spend much time trying to figure out how to
properly fix the test, and instead just set the modulestore to Old
Mongo.
For those tests that I didn't spend time investigating, I've set
the modulestore to TEST_DATA_MONGO_AMNESTY_MODULESTORE - search for
that string to find further work.
MST-1190. If the integrity signature flag has been enabled for a course, update the verified certificate description. The flag value should also be accessible to cert templates, so it has been added to the context.
[MICROBA-1594]
* Update course certificate generation logic when ID verification fails to check if the enrollment mode requires IDV.
This change fixes an issue where Honor certificates could not be generated in an Open edX installation unless a manual IDV override was added for the student.
The VERIFIED_NAME_FLAG, the VerifiedNameEnabledView, and the verified_name_enabled key removed from responses for both VerifiedNameView view and VerifiedNameHistoryView
were removed as part https://github.com/edx/edx-name-affirmation/pull/12. This was released in version 2.0.0 of the edx-name-affirmation PyPI package. Please see below for additional context for the removal, copied from the name-affirmation commit message.
The VERIFIED_NAME_FLAG was added as part https://github.com/edx/edx-name-affirmation/pull/12, [MST-801](https://openedx.atlassian.net/browse/MST-801) in order to control the release of the Verified Name project. It was used for a phased roll out by percentage of users.
The release reached a percentage of 50% before it was observed that, due to the way percentage roll out works in django-waffle, the code to create or update VerifiedName records was not working properly. The code was written such that any change to a SoftwareSecurePhotoVerification model instance sent a signal, which was received and handled by the Name Affirmation application. If the VERIFIED_NAME_FLAG was on for the requesting user, a Celery task was launched from the Name Affirmation application to perform the creation of or update to the appropriate VerifiedName model instances based on the verify_student application signal. However, we observed that when SoftwareSecurePhotoVerification records were moved into the "created" or "ready" status, a Celery task in Name Affirmation was created, but when SoftwareSecurePhotoVerification records were moved into the "submitted" status, the corresponding Celery task in Name Affirmation was not created. This caused VerifiedName records to stay in the "pending" state.
The django-waffle waffle flag used by the edx-toggle library implements percentage rollout by setting a cookie in a learner's browser session to assign them to the enabled or disabled group.
It turns out that the code that submits a SoftwareSecurePhotoVerification record, which moves it into the "submitted" state, happens as part of a Celery task in the verify_student application in the edx-platform. Therefore, we believe that because there is no request object in a Celery task, the edx-toggle code is defaulting to the case where there is no request object. In this case, the code checks whether the flag is enabled for everyone when determining whether the flag is enabled. Because of the percentage rollout (i.e. waffle flag not enabled for everyone), the Celery task in Name Affirmation is not created. This behavior was confirmed by logging added as part of https://github.com/edx/edx-name-affirmation/pull/62.
We have determined that we do not need the waffle flag, as we are comfortable that enabling the waffle flag for everyone will fix the issue and are comfortable releasing the feature to all users. For this reason, we are removing references to the flag.
[MST-1130](https://openedx.atlassian.net/browse/MST-1130)
IDV is on its way to retirement, so it's not going to be necessary for cert
generation forever.
Introduces a function to combine the honor code flag with IDV to tell
cert generation if it should care about a missing verification.
Various tests expanded to cover the retired case. The additional calls
in test_task_helper.py are caused by one call to fetch course
overrides which finds none, and that forces one check of the
background flag per student, 71 + 1 + 5 = 77.
MST-854
- Fixed LANGUAGE_COOKIE settings name to LANGUAGE_COOKIE_NAME beacuse later is recognised by django
- Added test to verify cookies use in dark lang middleware
- Fixing Django 3.0 tests
* 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
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
Certificate tests required an update to switch from boolean verified
flag to status. This feature is not deployed yet so only test uses
needed attention.
MST-969 and friends
If the certificate has an associated certificate date override, display
that date on the certificate instead of any other date. The date
override should not affect whether or not the certificate is visible /
available; only the date displayed on the certificate.
* refactor: Merge the openedx certs app with lms one
Move the certs API from openedx into the lms certificates app.
Functionally, this is a no-op. Cleanup will happen in a subsequent
commit. This is simply a move.
Beta testers can’t earn course certificates, so they should not see a “Request Certificate” button or other info describing how they can earn a cert.
MICROBA-992
If the verified name feature is enabled and the user has their
preference set to use verified name for certificates, create and
display certificates with their verified name rather than their
profile name.
[MICROBA-1354]
* Update Python API function named `cert_generated_enabled` to `has_self_generated_certificates_enabled` to more accurately reflect the purpose of the function
feat: reimagine certificate display settings
The course settings `certificate_available_date` (CAD) and
`certificates_display_behavior` (CDB) were previously
acting indedependantly of one another. They now work in
tandem. This change:
- limits CDB to a dropdown
- removes "early_with_info" and adds "end_with_date"
- only takes CAD into account if "end_with_date" is selected
- Moves CDB to the main course schedule settings page
- updates CourseOverview model and CourseDetails objects to
validate these fields and choose sane defaults if they aren't
expected values
This work was previously done in bd9e7dd (complete with bugs), so this
version is toggleable via the ENABLE_V2_CERT_DISPLAY_SETTINGS setting
[MICROBA-1087]
[DEPR-155]
* Removed callback functions that were originally used to update certificates (and example certificates) post xqueue processing
[MICROBA-1227]
[DEPR-155]
* remove queue.py (and associated unit tests)
* remove references to `queue.py` from functions in api.py (also update unit tests)
