If we wish this event to be sent to Segment through the event-tracking lib, we must ensure that the context includes at least the `user_id` field in the context dict.
* fix: add error handling for potential issues calculating course progress
Realized there is potential in a few places for exceptions to be thrown. I'm adding some more error handling in the course progress task and function to handle potential issues.
This PR attempts to improve the ability to collect analytics about learner's progress
in their courses. Currently, the only place we regularly calculate course progress is
when a learner visits the "Progress" tab in the courseware.
Now, _optionally_, when a learner visits the home page of their course, we will enqueue
a Celery task that will calculate their progress and emit a tracking event.
This event is gated by use of the COURSE_HOME_SEND_COURSE_PROGRESS_ANALYTICS_FOR_STUDENT
waffle flag.
DEPR: https://github.com/openedx/edx-platform/issues/36429
This change removes the course_sock and related API data. The UI it
removes is on the Legacy Courseware pages which have also been replaced
and have their own [deprecation ticket](https://github.com/openedx/edx-platform/issues/35803)
Before this can be merged, we will need to update the
frontend-app-learning MFE to no longer consume the
`can_show_upgrade_sock` attribute.
BREAKING CHANGE: CourseHomeMetadata, ProgressTab, OutlineTab and
VerifiedMode APIs will no longer have a `can_show_upgrade_sock`
attribute.
The courseware URL is going away but it's just used here to test the
middleware. That can be test with other urls that are relevant to this
middleware.
Note, I was unable to re-produce the failures so I've put back using the
standard `reverse` logic for fetching the URL in the test.
We want to remove this page and URL endpoint so we're removing all the
references in the code that might point to this page. It was replaced
by the sequences page in the Learning MFE years ago but the old pages
were never cleaned up. We are replacing the calls with the URL for the
courseware in the learning MFE.
See https://github.com/openedx/edx-platform/issues/35803 for more
details.
* fix: make the issued date displayed on previewed certificates match real certificates
This PR fixes an inconsistency in the dates displayed on certificates previewed via Studio with "real" certificates rendered to users.
It is possible for self-paced courses to be configured with a display behavior of "END" even though this configuration option should be invalid. The fix to this problem is beyond the scope of this PR. However, we can ensure we are selecting the correct display date for the certificate with a little bit of defensive coding.
I've added a check to ensure that we only use the end date of the course when the course is instructor-paced and configured with a display behavior of "END".
Fixes: https://github.com/openedx/platform-roadmap/issues/423
This PR updates the logic for determining the issued date shown on course certificates. For courses with a display behavior set to 'end date of the course', certificates earned by learners will now show the course run’s end date as the issued date.
Moves the Program Dashboard APIs out of the deprecated remnants of the legacy learner dashboard, into the Programs djangoapp.
Keeps the old legacy routes for this API, left over from the deprecated remnants of the legacy learner dashboard, alongside future-proofed routes which will work when the deprecated, legacy Program Dashboard is eventually replaced with functionality in the Learner Dashboard MFE.
FIXES: APER-3949
for Open edX operators who still have users with legacy PDF certificates, retirement requires first extracting information from the user's GeneratedCertificate record in order to delete the 4 associated files for each PDF certificate, and then removing the links to the relevant files. this creates a management command to do that work.
After thinking about it, I have removed the update to `status` from this management command, as per the original specification of the ticket. I added it for completeness originally, but was already uncomfortable, because it's not exactly accurate. The `CertificateStatuses` enum does define a `deleted` status:
```
deleted - The PDF certificate has been deleted.
```
but I think it's inappropriate to use here.
#### Why not use `CertificateStatuses.deleted` in the first place
There are multiple places in the code where it's clear that almost all of the statuses are legacy and unused (eg. [Example 1](6c6fd84e53/lms/djangoapps/certificates/data.py (L12-L34)), [Example 2](1029de5537/common/djangoapps/student/helpers.py (L491-L492))). There are innumerable APIs in the system that have expectations about what might possibly be returned from a `GeneratedCertificate.status` object, and none of them is expecting `deleted`
#### Why not revoke the certificate
Ultimately, the certificate isn't revoked, which has a specific meaning around saying it was unearned. The certificate was earned; it has simply been deleted. We should not be kicking off program certificate invalidation, because that's not what's happening. We should be trusting the normal user retirement process to remove/purge PII from any program certificates that might exist. The nature of web certificates simply means that we are going through this process outside of the normal retirement flow. The normal retirement flow can be trusted to implement any certificate object revocation/removal/PII-purging, and doing an extra step outside of that flow is counterproductive.
#### Why not robustly add a flow for `CertificateStatuses.deleted`
When PDF certificates were removed from the system, they weren't removed in their entirety. Instead, we have this vestigial remains of PDF certificates code, just enough to allow learners to display and use the ones that they already have, without any of the support systems for modifying them. Adding a `deleted` status, verifying that all other APIs wouldn't break in the presence of a certificate with that status, adding the signals to process and propagate the change: all of this would be adding more tech debt upon the already existing technical debt which is the PDF certs code. Better to simply add this one necessary data integrity change, and focus on a process which might allow us to eventually remove the web certificates code.
#### Why it is good enough to ignore the status
The original ask was simply to enforce data integrity: to remove links to files that have been deleted, as an indication that they've been deleted. I only added `status` update out of a (misplaced but well-intentioned) completionist urge.
FIXES: APER-3889
