ea3dc9cad6
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
Status: Active Responsibilities ================ The user_api app is currently a catch all that is used to provide various apis that are related to the user and also to features within the platform. Intended responsibility: To manage user profile and general account information and to provide APIs to do so easily. This includes the following features: user preference, user profile, user retirement, and account activation/deactivation. Direction: Decompose =============== Currently this app is a catch all for many user related information even when that information should really belong in a different app. If you are building a feature and need to provide information about a user within the context of your feature, you should localize that API to your feature and make your assumptions about what user information you need clear. For example authentication related APIs have already been moved to the user_authn django app. Glossary ======== More Documentation ==================