LG-10617 Consolidate in_person_enrollment methods#9052
Merged
Conversation
used this method to check for in_person_enrollments. the user has an establishing enrollment with an address selected which means they are ready for the next steps for in person proofing
changelog: Internal, IdV IPP, consolidate in_person_enrollment? methods
NavaTim
reviewed
Aug 22, 2023
tomas-nava
reviewed
Aug 23, 2023
kbighorse
suggested changes
Aug 25, 2023
Contributor
kbighorse
left a comment
kbighorse
left a comment
There was a problem hiding this comment.
Already a big improvement, my comments here are basically to continue to consolidate more aggressively.
The one wrinkle is to capture the distinction between establishing v. pending enrollments and do it in one place for all client callers to rely on rather than have to keep track of it themselves, which they don't really care about anyway. Maybe something like outstanding which resolves to establishing || pending or something like that?
Great work!
NavaTim
reviewed
Aug 25, 2023
Contributor
NavaTim
left a comment
NavaTim
left a comment
There was a problem hiding this comment.
It looks like the new logic should work out alright, but I would like to see how this affects the analytics (pending_in_person_enrollment field) before proceeding.
kbighorse
approved these changes
Aug 29, 2023
…fyForm#submit` There is a possibility that `User` has inconsistent enrollment data, so we trust the enrollment associated with its `pending_profile` object instead for safety. We capture this scenario in a new user spec. This can be re-implemented once enrollment data is consistent.
tomas-nava
reviewed
Aug 30, 2023
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🎫 Ticket
LG-10617
🛠 Summary of changes
Throughout the IdV flow we had many
in_person_enrollment?type methods which were all checking a form ofproofing_component.document_check == Idp::Constants::Vendors::USPS. This PR consolidates the methods onto the user class. Also instead of checking for the proofing component it checks to see if a user has an in person enrollment and if the selected_address is present.📜 Testing Plan
Provide a checklist of steps to confirm the changes.