-
Notifications
You must be signed in to change notification settings - Fork 115
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
LG-13761: ProofingComponents to store real vendor used to verify document PII #11499
Conversation
if idv_session.resolution_successful | ||
Idp::Constants::Vendors::AAMVA | ||
elsif idv_session.resolution_successful == false | ||
Idp::Constants::Vendors::AAMVA_UNSUPPORTED_JURISDICTION | ||
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.
A/N: This seems less than ideal, but there doesn't seem to be any good means to pulling the supplied vendor_name
out like I did in the VerifyInfoConcern#add_proofing_components
method.
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.
I think there are 2 options here:
- Add a value to the session to indicate whether we performed an AAMVA check and use that
- Inspect the value of the issuing jurisdiction in
pii_from_user
orpii_from_doc
and infer from that whether AAMVA was contacted
Option 1 may be slightly preferable since it stores the result of what the job actually does. The weakness is it involves adding another value to the session. As a result we'll need to break this into 2 deploys. One deploy to write the new value and a second to read and use it.
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.
Okay, I think I've addressed this here, so let me know what you think!
83f1022
to
dd97fcc
Compare
dd97fcc
to
41597e5
Compare
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.
Not leaving an approval as this is still marked as a draft and Hooper's comment implies a pending change, but 👍 to where it's at so far.
save_threatmetrix_status(form_response) | ||
save_source_check_vendor(form_response) |
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.
A/N: I feel like these two methods could be merged into an handle_success_updates_for_idv_session
method, but leaving as is for now.
@@ -38,6 +38,7 @@ | |||
allow(FeatureManagement).to receive(:proofing_device_profiling_collecting_enabled?). | |||
and_return(true) | |||
idv_session.threatmetrix_review_status = 'pass' | |||
idv_session.source_check_vendor = 'aamva' |
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.
A/N: Is there a better way to test this or is the captured by the end_to_end_idv feature spec?
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.
I think the VerifyInfoController (or the VerifyInfoConcern? I'm not sure which) should have a test asserting that the value in the result object is propagated to the Idv Session
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.
You are right, will add that now.
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.
The closest we get to validating the result object is in the end_to_end_idv
feature spec -- we have a method, #validate_verify_info_submit
, that validates the ProofingComponents structure, but not much else.
With respect to the controller specs, we primarily look at what value was logged in the event (with the exception of our threatmetrix status specs).
For now, I've updated the VerifyInfoController spec to look at what was logged in the state_id
stage and am open to expanding the coverage here.
@@ -46,6 +46,7 @@ def self.step_info | |||
idv_session.resolution_successful = nil | |||
idv_session.verify_info_step_document_capture_session_uuid = nil | |||
idv_session.threatmetrix_review_status = nil | |||
idv_session.source_check_vendor = nil |
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.
Do we have any specs for these undo_step things that need to be updated? Or do we just test this as a side effect of other tests
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.
As far as I can tell, we test undo state primarily as a side effect and only test defaults for individual classes.
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.
(I was waiting for the pipeline to complete to verify that assumption, so taking a look now)
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.
Yep, seems like undo step validation is primarily tested through feature specs.
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.
This is a nice fix, and it cleans up formatting a bit as well!
@@ -16,6 +16,9 @@ module Vendors | |||
MOCK = 'mock' | |||
USPS = 'usps' | |||
AAMVA = 'aamva' | |||
AAMVA_UNSUPPORTED_JURISDICTION = 'UnsupportedJurisdiction' | |||
STATE_ID_MOCK = 'StateIdMock' | |||
SOURCE_CHECK = [AAMVA, AAMVA_UNSUPPORTED_JURISDICTION, STATE_ID_MOCK].freeze |
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.
(Possible bikeshedding) Is there a clearer name for this? I.e., SOCURE
and LEXIS_NEXIS
are sources that we check; can we make it obvious why they don't belong in this array? STATE_ID_SOURCE_CHECK
?
Suggesting only in case you agree or have a better idea; I don't feel strongly at all here.
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.
I was on the fence about what to call this, but I wanted the relationship between this and ProofingComponents#source_check
to be clear and deeply coupled.
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.
I went back and forth about asking for state_id_source_check
, but the idea here is: you have given us a document of some kind. we then verify it with the issuing source. right now that is a drivers license + AAMVA. In the near future, hopefully, that will be other document types + other verifiers.
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.
Basically, source_check
is probably good
804fb5b
to
dfe0ab6
Compare
…ment PII **Why** * Prior to this change, we always stored 'aamva' in a `User`'s `proofing_components.source_check` column regardless of whether a call to AAMVA was made or not. Accuracy is good and storing the actual "vendor_name" will align our analytics across our events. **How** * Instead of hard-coding `vendor_name` in `proofing_components.source_check`, we dig into the result object (as produced by the `ResultAdjudicator`) for the actual vendor_name. This value should always be present even though we don't have any validators for it. * Adds `:source_check_vendor` field to `Idv::Session` to capture the vendor name actually utilized to validate the state ID attributes. * Pulling `vendor_name` from the result object makes testing a little messier, cleaning up the various vendor names in our specs should be done in future work. For now, a new constant with the known `source_check` names has been added (`Idv::Constants::Vendors::SOURCE_CHECK`). * No new specs have been added as the functionality hasn't changed, but the relevant specs, including one end-to-end feature test, have been updated to check the vendor name is in the expected list or matches a placeholder value. changelog: Internal, Analytics, Store correct vendor name in ProofingComponents
dfe0ab6
to
67fcdeb
Compare
@@ -33,7 +33,7 @@ def document_type | |||
end | |||
|
|||
def source_check | |||
Idp::Constants::Vendors::AAMVA if idv_session.verify_info_step_complete? | |||
idv_session.source_check_vendor |
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.
I think we need to tweak to account for the 50/50 state:
idv_session.source_check_vendor | |
idv_session.source_check_vendor || (Idp::Constants::Vendors::AAMVA if idv_session.verify_info_step_complete?) |
(you can probably come up with a better / more ruby-ish way to do ☝️ )
Basically, if the key is not in the session, we need to fall back to the old (bad) way
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.
Fixed!
let(:document_capture_session) do | ||
DocumentCaptureSession.create(user:) | ||
end | ||
|
||
let(:success) { true } | ||
let(:errors) { {} } | ||
let(:exception) { nil } | ||
let(:vendor_name) { :aamva } | ||
let(:vendor_name) { 'aamva_placeholder' } |
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.
will not approve without emoji vendor name
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.
All this looks good, just the one 50/50 state thing
Why
User
'sproofing_components.source_check
column regardless of whether a call to AAMVA was made or not. Accuracy is good and storing the actual "vendor_name" will align our analytics across our events.How
Instead of hard-coding
vendor_name
inproofing_components.source_check
, we dig into the result object (as produced by theResultAdjudicator
) for the actual vendor_name. This value should always be present even though we don't have any validators for it.This makes testing a little messier, but cleaning up the various vendor names in our specs should be done in future work. For now, a new constant with the known
source_check
names has been added (Idv::Constants::Vendors::SOURCE_CHECK
).No new specs have been added as the functionality hasn't changed, but one end-to-end feature test has been updated to check the vendor name is in the expected list.
changelog: Internal, Analytics, Store correct vendor name in ProofingComponents
🎫 Ticket
Link to the relevant ticket:
LG-13761
📜 Testing Plan
Provide a checklist of steps to confirm the changes.