Conversation
…ng waiting should allow access to account page
|
|
||
| def signed_in_url | ||
| return url_for_pending_profile_reason if user_has_pending_profile? | ||
| return idv_verify_by_mail_enter_code_url if current_user.gpo_verification_pending_profile? |
There was a problem hiding this comment.
url_for_pending_profile_reason also redirects for profiles that have fraud_review_pending or fraud_rejection status. I think we should change the behavior of that method, not remove it here. And add feature specs that confirm that users are redirected as expected - I'm surprised nothing failed.
I was going to run the in_person feature spec to get a look at idv_in_person_ready_to_verify_url and see if the user would still need to be able to get there, but my local setup won't run feature specs suddenly :-(. Do we have a banner on the account page to allow the user to access that page?
There was a problem hiding this comment.
@soniaconnolly Does the discussion at #9410 (comment) help contextualize the reason for the change? My fear with modifying url_for_pending_profile_reason is that method is used elsewhere like IdvController where we'd want the fraud review and fraud rejection screens to be shown, but we don't want those to be shown when signing in at IAL1.
There was a problem hiding this comment.
Oh, I see. That makes more sense, thanks.
aduth
left a comment
aduth
left a comment
There was a problem hiding this comment.
I ran through this locally for all of the pending states (GPO, IPP, fraud review, fraud rejection) at both IAL1 and IdV and it worked as expected for me in all cases 👍
Left a note about a lingering test failure I'm hopeful should be straightforward to address.
…unt-page-in-person-proofing
3 participants
🎫 Ticket
LG-11128
🛠 Summary of changes
User in verification would not be able to get access to their account page right now, this would allow them to get through.