LG-13005: use TransactionStatus to determine if document passed TrueID #10427
Conversation
amirbey
changed the title
amirbey
force-pushed
the
amirbey/spike-LG-13005
branch
from
90e9a1b
to
dfd28c5
Compare
amirbey
force-pushed
the
amirbey/spike-LG-13005
branch
2 times, most recently
from
2ad7495
to
77d0f4e
Compare
amirbey
force-pushed
the
amirbey/spike-LG-13005
branch
from
77d0f4e
to
a7db0c5
Compare
amirbey
changed the title
amirbey
force-pushed
the
amirbey/spike-LG-13005
branch
2 times, most recently
from
2c9f414
to
b501648
Compare
amirbey
changed the title
| "ProductStatus": "pass", | ||
| "ProductStatus": "fail", |
There was a problem hiding this comment.
Can you say more about these changes (also in some of the other fixtures)? I could be mistaken but I thought these were direct responses from TrueID and this PR is to change what field we rely on from TrueID, and not that the TrueID response itself has changed.
There was a problem hiding this comment.
@night-jellyfish - yes, you are correct ... this change is about relying on a different field (transaction_status)! 👍🏿
while we will not be evaluating product_status ... in our prod events.log, it is consistent that product status and transaction status either both pass or both fail. however, it seems there is a discrepancy in many of our fixtures.
There was a problem hiding this comment.
Interesting! I guess I was worrying a little that I thought our fixtures were taken directly from requests to the API (and then anonymized). So that would imply to me that maybe the values could be opposing. But maybe I'm wrong about how they were created and this isn't a concern.
app/services/doc_auth/lexis_nexis/responses/true_id_response.rb
Outdated
Show resolved
Hide resolved
| return false unless id_type_supported? | ||
| return false if transaction_status_from_uploaded_file == 'failed' | ||
| return true if transaction_status_from_uploaded_file == 'passed' | ||
| return false if doc_auth_result_from_uploaded_file == 'Failed' |
There was a problem hiding this comment.
Is this line in case there are yml files out there that haven't implemented transaction_status?
If so, it does seem like it could be worthwhile enforcing folks to include that, rather than keeping this method for old code.
There was a problem hiding this comment.
good point .. currently we do not force folks to include doc_auth_result ... so replicating this behavior with transaction_status
| @@ -166,15 +183,23 @@ def classification_info | |||
| end | |||
|
|
|||
| def doc_auth_result_from_success | |||
There was a problem hiding this comment.
I wonder if we still need this method? It seems possible that we could refactor this away if we aren't using the doc_auth_result for any logic.
| DocAuth::LexisNexis::ResultCodes::PASSED.name | ||
| else | ||
| DocAuth::LexisNexis::ResultCodes::CAUTION.name | ||
| end | ||
| end | ||
|
|
||
| def all_doc_capture_values_passing?(doc_auth_result, id_type_supported) | ||
| doc_auth_result == 'Passed' && | ||
| def transaction_status_from_success |
There was a problem hiding this comment.
this name is confusing to me - I'm not sure I understand the from_success piece.
There was a problem hiding this comment.
continuing the pattern used in doc_auth_result_from_success this is if the document is authenticated successfully
changelog: Internal, Document Authentication, TrueIDReponse successful if transaction status passes
…d when counting errors
…ionStatus is ...'
amirbey
force-pushed
the
amirbey/spike-LG-13005
branch
from
b1ed85a
to
bf691c9
Compare
#10427) * doc auth pass if transaction status passes changelog: Internal, Document Authentication, TrueIDReponse successful if transaction status passes * update spec response transaction status * update true id response spec * update fixtures product status for failed transactions * update product status * selfie must past * revert fixture changes * update trueID response specs for transaction status * attention barcode does not have to be only error * update doc_auth_success to remove selfie in mock result response * happy linting * allow mock proofer to have multiple errors with barcode attn * remove dup test * add an error barcode fixture to barcode error trueid response * ensure attention_with_barcode? returns a boolean * update spec attention with barcode * error generator use transaction status to determine if doc auth passed when counting errors * consolidate checking if doc auth passed in error generator * doc_auth_passed not in scope for DocAuthErrorHandler * update mock to include transaction_status * rename error generator tests from 'DocAuthResult is ...' to 'TransactionStatus is ...' * fetch transaction_status from yml image files * update analytics expectation with transaction_status value * update analytics expectation with transaction_status value * update analytics expectation with transaction_status value * update transaction_stauts in mock to reflect doc auth only * check transaction status to determine if doc auth is sucess for mock * assist with correcting case for transaction status and doc auth result in yml files * do not correct case * add transaction status to yml * add transaction status to yml * add transaction status to yml * add transaction result to inline yaml files * update yml fixtures to have transaction_status * update image upload presenter to use transaction status * upate image upload presenter spec to receive transaction status * remove stale comment
🎫 Ticket
Link to the relevant ticket:
LG-13005
🛠 Summary of changes
Use TrueIdResponse transaction status value (passed/failed) to determine if the document was successfully authenticated.
📜 Testing Plan
Provide a checklist of steps to confirm the changes.
transaction_status: passedtransaction_status: failedtransaction_status: passedand2D Barcode Readerror after user confirms name and DOB