Refactor part of Wallet_Activate into VerifyIdentity

[MariaHCD]

Hold on: https://github.com/Expensify/Web-Expensify/pull/34343

Details

Fixed Issues

$ https://github.com/Expensify/Expensify/issues/218501

Tests

Pre-requisites:

1. Have an account with a pending wallet (all new accounts have a pending wallet created automatically)
2. Get access to LexisNexis as this service is required on the AdditionalDetails Step which you'll need to complete before moving forward to the OnfidoStep:

• Run the following commands:

nslookup webapi.libertydata.net
nslookup wsonline.seisint.com

Each one will return one or more address fields. For each of those, run:

sudo route add -net ADDRESS/32 172.16.106.1

For the three addresses I got back, this means the actual commands I run are:

sudo route add -net 209.243.48.97/32 172.16.106.1
sudo route add -net 50.79.80.169/32 172.16.106.1
sudo route add -net 65.144.58.53/32 172.16.106.1

• Now, you'll need to mockup a successful response from Idology.
• Note: To retest with the same wallet bank account, run the following to reset the KYC flow:

UPDATE bankAccounts SET additionalData = JSON_SET(COALESCE(NULLIF(additionalData, ''), '{}'), '$.verifications', JSON('{}')) WHERE bankAccountID = 40;

UPDATE bankAccounts SET additionalData = JSON_SET(COALESCE(NULLIF(additionalData, ''), '{}'), '$.currentStep', 'AdditionalDetailsStep') WHERE bankAccountID = 40;

Tests:

1. Navigate to /enable-payments, fill out the additional details form
2. You'll now see the Onfido Privacy page and will be taken through the Onfido flow as shown below. (Note: proceed through the flow without using any of your own ID if you can avoid it - Onfido recommends to not use real info)

3. Verify you can complete the process successfully:

• If the check passes or wasn't able to complete synchronously, you'll be directed to the Terms page.

• If the check didn't pass and you had some fixable errors, those errors will be displayed and you can retry the flow again. You can mock some fixable errors by setting $didPass to false and $onfidoFixableErrors to:

$onfidoFixableErrors = [Onfido_API::ERROR_IMAGE_QUALITY, Onfido_API::ERROR_SELFIE];

To mock fixable errors in Onyx:

let data = {
    errors: { 1660306327299659: "Sorry we're unable to verify your identity. Please fix the errors before continuing." },
    fixableErrors: [
        "There's an issue with your selfie/video. Please upload a new selfie/video in real time."
    ]
};
Onyx.merge('walletOnfido', data);

• If the check failed, you'll be directed to the failed KYC page. You can mock this failure by throwing:

throw new IdentityVerificationError('3D9B8AC1-C2C0-49CC-B817-7660A0E72EE7', IdentityVerificationError::VERIFICATION_ERROR]);

PR Review Checklist

Contributor (PR Author) Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • iOS / native
  • Android / native
  • iOS / Safari
  • Android / Chrome
  • MacOS / Chrome
  • MacOS / Desktop
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I followed proper code patterns (see Reviewing the code)
  • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text shown in the product was added in all src/languages/* files
  • I verified any copy / text that was added to the app is correct English and approved by marketing by tagging the marketing team on the original GH to get the correct copy.
  • I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
  • I verified the JSDocs style guidelines (in STYLE.md) were followed
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
• I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
• I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
• If a new component is created I verified that:
  • A similar component doesn't exist in the codebase
  • All props are defined accurately and each prop has a /** comment above it */
  • Any functional components have the displayName property
  • The file is named correctly
  • The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
  • The only data being stored in the state is data necessary for rendering and nothing else
  • For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
  • Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
  • All JSX used for rendering exists in the render method
  • The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

PR Reviewer Checklist

The Contributor+ will copy/paste it into a new comment and complete it after the author checklist is completed

• I have verified the author checklist is complete (all boxes are checked off).
• I verified the correct issue is linked in the ### Fixed Issues section above
• I verified testing steps are clear and they cover the changes made in this PR
  • I verified the steps for local testing are in the Tests section
  • I verified the steps for Staging and/or Production testing are in the QA steps section
  • I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
• I checked that screenshots or videos are included for tests on all platforms
• I verified tests pass on all platforms & I tested again on:
  • iOS / native
  • Android / native
  • iOS / Safari
  • Android / Chrome
  • MacOS / Chrome
  • MacOS / Desktop
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I verified proper code patterns were followed (see Reviewing the code)
  • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text shown in the product was added in all src/languages/* files
  • I verified any copy / text that was added to the app is correct English and approved by marketing by tagging the marketing team on the original GH to get the correct copy.
  • I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
  • I verified the JSDocs style guidelines (in STYLE.md) were followed
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I verified that this PR follows the guidelines as stated in the Review Guidelines
• I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
• I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
• I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
• If a new component is created I verified that:
  • A similar component doesn't exist in the codebase
  • All props are defined accurately and each prop has a /** comment above it */
  • Any functional components have the displayName property
  • The file is named correctly
  • The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
  • The only data being stored in the state is data necessary for rendering and nothing else
  • For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
  • Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
  • All JSX used for rendering exists in the render method
  • The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

QA Steps

• None. We'll test the entire KYC process internally once all the steps have been refactored.

Screenshots

Web

Added in test steps

Mobile Web

[melvin-bot]

Hey! I see that you made changes to our Form component. Make sure to update the docs in FORMS.md accordingly. Cheers!

[MariaHCD]

Conflicts fixed. On hold till the Web PR goes out to prod but this is ready for reviews @marcochavezf @marcaaron @francoisl!

[MariaHCD]

Off hold!

[marcochavezf]

The code LGTM but I can't test it locally because for some reason I'm not getting the Verify Identity page yet.

For the three addresses I got back, this means the actual commands I run are:
sudo route add -net 209.243.48.97/32 172.16.106.1
sudo route add -net 50.79.80.169/32 172.16.106.1
sudo route add -net 65.144.58.53/32 172.16.106.1

Not sure it's related to the problem, but I got only two addresses in the pre-requisite steps.

---

Also I found an issue that I think is not related to the PR: When I try to fill out the Additional details (which is the first page that appears when I navigate to /enable-payments) the server error is not displayed in the front-end:

[francoisl]

Not sure it's related to the problem, but I got only two addresses in the pre-requisite steps.

I only had two addresses as well, and it worked. Is it possible you didn't mock the response from IDology here, and it failed at that step? Alternatively, you might be able to skip directly to the Onfido step by running this query (replace the bankAccountID with your wallet's ID):

UPDATE bankAccounts SET additionalData = JSON_SET(COALESCE(NULLIF(additionalData, ''), '{}'), '$.currentStep', 'OnfidoStep') WHERE bankAccountID = XXX;

[MariaHCD]

Not sure it's related to the problem, but I got only two addresses in the pre-requisite steps.

Nope, should be all good. I got two addresses as well :)

I can't test it locally because for some reason I'm not getting the Verify Identity page yet.

As @francoisl said, you'll need to mock the response from IDology here and you should be good to go.

Also I found an issue that I think is not related to the PR: When I try to fill out the Additional details (which is the first page that appears when I navigate to /enable-payments) the server error is not displayed in the front-end:

Thanks for catching that! Its probably related to the other refactor PR: https://github.com/Expensify/Web-Expensify/pull/34326. Working on a separate PR to fix that.

[marcaaron]

This is missing a JSDoc with the @returns, but would recommend reverting most of these changes. They are unrelated to the current changes (I'm having trouble telling exactly what changed about this file otherwise) and I think we normally recommend to keep as much JSX inline as possible (though I'm not sure if this is established somewhere in the style guide or just clash of personal preference).

[marcochavezf]

Alternatively, you might be able to skip directly to the Onfido step by running this query (replace the bankAccountID with your wallet's ID):

UPDATE bankAccounts SET additionalData = JSON_SET(COALESCE(NULLIF(additionalData, ''), '{}'), '$.currentStep', 'OnfidoStep') WHERE bankAccountID = XXX;

Thanks this helped! Also, I found in this SO that I had to enter 3333 in the SSN field to continue 😄

[marcaaron]

Looks great!

[OSBotify]

✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

[OSBotify]

🚀 Deployed to staging by @francoisl in version: 1.1.89-0 🚀

platform	result
🤖 android 🤖	success ✅
🖥 desktop 🖥	success ✅
🍎 iOS 🍎	success ✅
🕸 web 🕸	success ✅