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)
If COPPA compliance feature flag is enabled, remove the `primary/elementary` option
from the level of education dropdown field on edit but keep the value showing for
the users who have already selected it.
VAN-762
The use of useState and useEffect hooks in the IDVerificationContextProvider and VerificationContextProvider that were unnecessary was triggering many extra re-renders and inappropriate renders, causing a UI flicker across multiple re-renders.
Removes confusing wording where alerts and help text would state that
the changed name would be used on certificates once approved,
even if it wasn't the name that was selected to be used on certificates.
[MST-1099](https://openedx.atlassian.net/browse/MST-1099)
Due to a bug in the way the canVerify React state is being set, when the verified name feature is enabled, the code inconsistently loads either the AccessBlocked panel or the ReviewRequirementsPanel when the learner should be allowed to verify. If the learner is ineligible to complete IDV due to their IDV history (e.g. they already have an approved IDV), and the verified name feature is enabled, the learner should be able to verify and should not see the AccessBlocked panel. This code change fixes this bug.
This code change also fixes flickering that occurs when IDV is loading. This code change also includes some copy fixes.
[MST-1065](https://openedx.atlassian.net/browse/MST-1065)
When the Name Affirmation feature is enabled, a few panels in the IDV workflow should have different copy to reflect the changes associated with Name Affirmation. This is because entering a new during the IDV flow (GetNameIdPanel) will no longer modify the learner's "Account Name". Furthermore, "Account Name" is an ambiguous term; it's not clear that it refers to the learner's full name on their profile. These copy changes make the panel more generic and remove details about name changes. The SummaryPanel also has a minor copy change to change "Account Name" to "Name".
These code changes also include some UI changes.
