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)
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 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-1298]
* Remove a Segment certificate event that was, historically, only emit from the courseware.
The Segment event that was previously (only) issued in the courseware doesn't seem to be important or referenced anywhere we could see. Since this event only tracked certificate generation attempts from one (of multiple) paths to initiate certificate generation in v1, I didn't think the historical event data captured is complete. We approached our data teams and I determined this event was not of high importance. For this reason, I am suggesting we just stop using this event and remove the code responsible for sending it.
We will continue to track certificate creation/generation using the existing `edx.certificate.created` event.
[MB-1077]
- Stop removing the verify_uuid when revoking course certificates. In v2 of course certificates this will allow us to retain the same URL to the certificate. If a learner's certificate is revoked (from being invalidated or no longer passing the course) the UUID will remain intact and the URL will not change.
- Look for an existing cert for the user in a course-run during generation. If one exists, use the UUID from the existing certificate when updating the record.
- Stop generating a `key` for v2 web-certificates. This is not needed for web-certs (this is used in PDF cert generation).
