LG-13005: use TransactionStatus to determine if document passed TrueID#10427
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
| "ExecutedStepName": "True_ID_Step", | ||
| "ProductConfigurationName": "AndreV3_TrueID_Flow", | ||
| "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.
|
|
||
| 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
night-jellyfish
left a comment
night-jellyfish
left a comment
There was a problem hiding this comment.
Tested out manually as per the testing instructions, and it all worked! 🎉
There are still some comments unresolved from me, but I don't think there are any that are blocking.
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
2 participants
🎫 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