[APER-3385]
This PR fixes an existing management command that now has incorrect logic. We have recently done a lot of work to
improve certificate-related date business logic to fix data inconsistencies between systems. Instead of maintaining
separate and duplicated logic for sending date data to Credentials, instead we can use an existing (and tested)
Celery task that will determine and send the correct date to the Credentials IDA.
Additionally, the original version of this management command skipped self-paced courses completely. This is no
longer the case as we _know_ that there are self-paced courses that have been associated with a certificate available
date because of bugs in the product. This management command will serve as a means to do a mass data fixup for data stored by the Credentials IDA.
This PR removes the `clean_certificate_available_date` management command. Recently, a change was made to sync the end date of a course run with a display behavior of "end" as its certificate available date in the Credentials IDA. This change was made to resolve a long running issue with the Credentials IDA not displaying certificates to learners correctly on learner records when the display behavior is set to "end".
This management command, if run, would clear the certificate available date from the course certificate configurations in the Credentials IDA. This would be a regression based on the new functionality. Other improvements have been made to ensure that updates made in the LMS properly flow to Credentials.
TL;DR -- this management command is no longer needed because of feature changes in edx-platform. Allowing this management command to run would break functionality for learners.
[APER-3229]
In a previous PR, I created a new utility function named `is_credentials_enabled()` that can be used to determine if use of the Credentials IDA is enabled by config in an Open edX instance.
This PR is some additional cleanup that replaces the direct import and use of the `CredentialsApiConfig` model with the new utility function.
I took some additional time to update some existing log messages to include more info while reducing our need to log PII. I've removed as much use of a learner's username as possible, replacing it with logging the learner's LMS User Id instead.
[APER-2504]
This is a companion to PR #32458. This updates the `notify_credentials` management command and adds an additional argument/switch (`--revoke_program_certs`).
If included, this option will be converted to a boolean and passed as a script option. Eventually, the `send_notifications` function (updated in the previously mentioned PR) will determine if we should fire a signal that checks if any program certs need to revoked.
[APER-2504]
This PR adds additional functionality to the tasks kicked off when the `notify_credentials` management command is run.
I have added a new keyword arg (revoke_program_certs) that, if True, will check to see if we need to revoke a program certificate. This functionality was introduced to help automate fixing cases where a learner still has access to a Program Certificate even if they have been awarded all of the course certificates in a Program (see APER-2499).
The functionality has to be committed in two separate PRs because of our blue/green deployments. The task changes will come first, then we will update the management command to be able to set/pass the new settings. New settings were added as keyword args (defaulting to False) in order to ensure that we won't trip up our workers.
[APER-1968]
We don't have a good way to understand if grade data in Credentials is out of sync with the LMS. Grades are sent to Credentials via a REST API call originating from an asynchronous Celery task on the LMS side. This PR updates our Celery task `send_grade_to_credentials` to include sending the `modified` DateTime value of a grade record to the Credentials IDA. Updates will be made on the Credentials side to accept and store this data as part of the UserGrade instance.
* Updates the `send_grade_to_credentials` task to include passing the grade's `modified` DateTime info as part of the request data to Credentials
* Updates the `CourseGradeBase` class to include an optional `last_updated` field. This will store the `modified` date of a PersistentCourseGrade instance when a grade is read through the CourseGradeFactory.
* Update existing log statement to use format strings where possible.
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
* [fix] Certificate availability date cleanup
This task will clean out the misconfigured certificate available date. When courses Change their
certificates_display_behavior, the certificate_available_date was not updating properly. This is
command is meant to be ran one time to clean up any courses that were not supposed to have
certificate_available_date
[refactor] change backfill date task to long running task
Change from a task that spins off multiple other tasks to a single long
running task. This will hopefully be way less heavy when this is ran in
production.
* [refactor] Move backfill_date_for_all_course_runs to Tasks.py
In order for celery to register this task, it needs to be in the right
file. duh!
* fix imports
* fix more imports
Before this change, the notify_credentials management command ran for
about 10-15 minutes and occasionally overlapped with an edxapp
deployment which would cause the machine the command was running
on to die. The command ran through a bunch of certs and grades, and then
spun off celery tasks to send the relevant data to credentials.
Now, most of the logic of the notify_credentials management command has
been moved into a new celery task, so that combing through longs lists
of certs and grades is done asynchronously. This task then spins off the
original data-sending tasks as before.
Note that this requires a change in alerting: where the jenkins job
would previously notify us about failures, we need to know when this
new celery task fails for any reason. We’ve made this a LoggedTask
so that failures will be logged to Splunk and alerting can be built off
of the error messages.
This commit also moves the relevant tests.
MICROBA-963
