-
Notifications
You must be signed in to change notification settings - Fork 166
LG -7015 Redirect user to "Sorry" page on TMX verification failure #6827
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
160f320
f88db8b
71f9d23
2f818c8
d71b9d9
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -51,6 +51,8 @@ def completion_url(result, user) | |
| idv_come_back_later_url | ||
| elsif in_person_enrollment?(user) | ||
| idv_in_person_ready_to_verify_url | ||
| elsif device_profiling_failed?(user) | ||
| idv_come_back_later_url | ||
| elsif current_sp | ||
| sign_up_completed_url | ||
| else | ||
|
|
@@ -63,6 +65,14 @@ def in_person_enrollment?(user) | |
| ProofingComponent.find_by(user: user)&.document_check == Idp::Constants::Vendors::USPS | ||
| end | ||
|
|
||
| def device_profiling_failed?(user) | ||
| return false unless IdentityConfig.store.proofing_device_profiling_decisioning_enabled | ||
| proofing_component = ProofingComponent.find_by(user: user) | ||
| # pass users who are inbetween feature flag being enabled and have not had a check run. | ||
| return false if proofing_component.threatmetrix_review_status.nil? | ||
| proofing_component.threatmetrix_review_status != 'pass' | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ditto about checking if this is nil?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do you mean checking if proofing_component is nil or if threatmetrix_review_status is nil?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I meant
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I have a test for review status being nil and it returns
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ah I see, so my expectation is that review status being nil is not a failure, that this method should return falsy in that case? Becaue we don't know that it's a for sure negative? and there may be users who fit into a gap of "the feature flag was enabled but we didn't run the check for them" so they don't have data
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ah so if it is nil let them pass?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. yeah that's my expectation of how we could ensure the safest/smoothest launch
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd like to add my support to the idea that a missing |
||
| end | ||
|
|
||
| def handle_request_enroll_exception(err) | ||
| analytics.idv_in_person_usps_request_enroll_exception( | ||
| context: context, | ||
|
|
||
| Original file line number | Diff line number | Diff line change | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
@@ -37,6 +37,8 @@ def next_step | |||||||||||||||||||||||
| idv_come_back_later_url | ||||||||||||||||||||||||
| elsif in_person_enrollment? | ||||||||||||||||||||||||
| idv_in_person_ready_to_verify_url | ||||||||||||||||||||||||
| elsif device_profiling_failed? | ||||||||||||||||||||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Note that there are currently two implementations of the personal key step, controlled by the The other:
|
||||||||||||||||||||||||
| idv_come_back_later_url | ||||||||||||||||||||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. we'll change this once we have real content, right?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I feel like this PR should also include a new stub page like
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. yep |
||||||||||||||||||||||||
| elsif session[:sp] && !pending_profile? | ||||||||||||||||||||||||
| sign_up_completed_url | ||||||||||||||||||||||||
| else | ||||||||||||||||||||||||
|
|
@@ -82,5 +84,13 @@ def in_person_enrollment? | |||||||||||||||||||||||
| def pending_profile? | ||||||||||||||||||||||||
| current_user.pending_profile? | ||||||||||||||||||||||||
| end | ||||||||||||||||||||||||
|
|
||||||||||||||||||||||||
| def device_profiling_failed? | ||||||||||||||||||||||||
| return false unless IdentityConfig.store.proofing_device_profiling_decisioning_enabled | ||||||||||||||||||||||||
| proofing_component = ProofingComponent.find_by(user: current_user) | ||||||||||||||||||||||||
| # pass users who are inbetween feature flag being enabled and have not had a check run. | ||||||||||||||||||||||||
| return false if proofing_component.threatmetrix_review_status.nil? | ||||||||||||||||||||||||
| proofing_component.threatmetrix_review_status != 'pass' | ||||||||||||||||||||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think we need to make sure it's also not nil |
||||||||||||||||||||||||
| end | ||||||||||||||||||||||||
| end | ||||||||||||||||||||||||
| end | ||||||||||||||||||||||||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -204,5 +204,33 @@ def index | |
| expect(response).to redirect_to idv_in_person_ready_to_verify_url | ||
| end | ||
| end | ||
|
|
||
| context 'with device profiling decisioning enabled' do | ||
| before do | ||
| ProofingComponent.create(user: user, threatmetrix: true, threatmetrix_review_status: nil) | ||
| allow(IdentityConfig.store). | ||
| to receive(:proofing_device_profiling_decisioning_enabled).and_return(true) | ||
| end | ||
|
|
||
| it 'redirects to account path when threatmetrix review status is nil' do | ||
| patch :update | ||
|
|
||
| expect(response).to redirect_to account_path | ||
| end | ||
|
|
||
| it 'redirects to account path when device profiling passes' do | ||
| ProofingComponent.find_by(user: user).update(threatmetrix_review_status: 'pass') | ||
| patch :update | ||
|
|
||
| expect(response).to redirect_to account_path | ||
| end | ||
|
|
||
| it 'redirects to come back later path when device profiling fails' do | ||
| ProofingComponent.find_by(user: user).update(threatmetrix_review_status: 'fail') | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. can we get some tests with statuses like |
||
| patch :update | ||
|
|
||
| expect(response).to redirect_to idv_come_back_later_path | ||
| end | ||
| end | ||
| end | ||
| end | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To me it feels like a confusing double negative to say that the user passes the test if device_profiling_failed is false. It could be named
device_profiling_passed?and return true when the user passes. Or, I would also find the nameblocked_by_device_profiling?clearer if you still want it to return false on a pass.