The _does_name_change_require_verification(user_profile, old_name, new_name) method of the accounts user_api determines whether a learner can change their name from old_name to new_name. Originally, it delegated solely to the NameChangeValidator class of the edx-name-affirmation API, which ran a set of checks against the name change. One of said checks was asserting that learners with one or more certificates could not change their name without completing IDV.
This pull request changes this behavior.
Learners may have certificates that are not in a passable status (e.g. "unverified"). We only want to require IDV for name changes for learners that have passing statuses. The existing code prevented learners from changing their name if they had any certificates at all, irrespective of the certificate status. This change only considers certificates in a passable status.
Additionally, learners may have certificates and also not be enrolled in any "verified" seats. For example, despite edX no longer offering "honor" seats, learners may have enrollments in "honor" modes, which grant certificates but are not considered "verified" enrollment modes. IDV requires that a learner be enrolled in a "verified" seat in order to complete IDV. Prior to this change, learners that were navigated to IDV to validate a name change were unable to complete IDV. This change introduce a check that a learner is in a "verified" mode in addition to using the NameChangeValidator. This prevents the account MFE from navigating an IDV-ineligible learner to IDV.
MST-1254: https://openedx.atlassian.net/browse/MST-1254
The language cookie "samesite" attribute was always set to "None", even in
non-secure environments, such as the devstack. This was causing client-side
warnings in non-https environments, and the language cookie was not properly
set.
Suppress them both in tests (via setup.py and pytest.ini)
and in management command & application runs
(via logsettings.py).
Developers aren't looking at these warnings; they'll be dealt with in a
formal process for upgrading Django. Suppress them for now so that
important information isn't lost in the noise.
This will avoid leaking whether a course exists or not to anonymous
users and also avoid some false-positive error rates when web
crawlers hit bad URLs.
