Refactor part of ActivateWallet into UpdatePersonalDetailsForWallet

[Gonals]

Details

Fixed Issues

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

Tests

Ready? This is a pain to test! Gotta be tested with https://github.com/Expensify/Web-Expensify/pull/34326

1. You first need to get access to LexisNexis:
   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

2. Now, you'll need to mockup a successful response from Idology.

3. Now you can start testing! From an account with a Wallet, on NewDot, request money from another account that does NOT have a wallet yet.

4. Log into the walletless account and try to pay (you may need to add a debit card first for the "Pay with Expensify" button to show up). You'll be taken to the additional details page:
   https://github.com/Expensify/Web-Expensify/pull/34326/files#diff-e4dfb4153823fd1c467ff673d4bfb99adca4b88ee20e20ba73ca86fc2fcc8433R1069

5. Fill the details with mockup stuff. Chances are the SSN number will fail and it will ask for a full number:

7. Fill the full number and click "Save&Continue". You should get to the identity step. Congrats!:

8. Now it is time to test some of the errors! The mockup response is actually pretty complete in this sense, so we just need to change some checks to mockup the behavior. Remove the ! here for $didPass to mockup the questions behavior. If you got through the additional details steps again, you should get a few questions like these:

9. Now, in addition to that one, also remove the ! for the question count here. Repeat the steps again and it should take you to:

10. To test the offline behavior, stay online until you open the Additional details form and then go offline. You should see the message and the button should get disabled:

And I think that should be enough!

• Verify that no errors appear in the JS console

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

This needs to be QAed from the US, I believe.

1. From an account with a fully authenticated Wallet, on NewDot, request money from another account that does NOT have a verified wallet yet (so the wallet is in a pending state). All accounts on expensify/expensifail should have a pending wallet. You'll need both of them to be in the wallet beta and the payWithExpensify beta

2. On OldDot, log into the account with the pending wallet and go to Settings>Account>Payments and add a debit card. You can use one of these test cards.

3. Log into the account with the pending wallet on NewDot and try to pay (you may need to add a debit card first for the "Pay with Expensify" button to show up). You'll be taken to the additional details page:
   https://github.com/Expensify/Web-Expensify/pull/34326/files#diff-e4dfb4153823fd1c467ff673d4bfb99adca4b88ee20e20ba73ca86fc2fcc8433R1069

4. Fill the details with mockup stuff. Chances are the SSN number will fail and it will ask for a full number:

5. Fill the full number and click "Save&Continue". You should get to the identity step. Congrats!:

• Verify that no errors appear in the JS console

Screenshots

Web

Mobile Web

Desktop

iOS

Android

[chiragsalian]

Please explain why the PR is on HOLD in the PR description or a comment 🙂
I'm assuming its for the backend changes and if so link the PR someplace.

[Gonals]

Please explain why the PR is on HOLD in the PR description or a comment 🙂 I'm assuming its for the backend changes and if so link the PR someplace.

Yep! I'll have that PR ready tomorrow, hopefully!

[chiragsalian]

is it ready for review or are you still working on the PR?

[Gonals]

is it ready for review or are you still working on the PR?

Ready!

[chiragsalian]

Minor comments. Rest LGTM i think.

[Gonals]

Finally, shouldn't this PR be internalQA. I don't think applause team has a gold wallet to test this but correct me if i'm mistaken.

I think you may be right, yeah. Good catch!

[Gonals]

Comments addressed!

[chiragsalian]

LGTM

[melvin-bot]

Triggered auto assignment to @youssef-lr (InternalQA), see https://stackoverflow.com/c/expensify/questions/5042 for more details.

[melvin-bot]

@chiragsalian looks like this was merged without passing tests. Please add a note explaining why this was done and remove the Emergency label if this is not an emergency.

[chiragsalian]

Hmm, melvin derping. Not emergency and travis tests had passed. Looks like internalQA assignment is firing too early. Removing Youssef.

[mvtglobally]

@Gonals @chiragsalian @MariaHCD Can this PR be QAed internally? We do not have a valid account with wallet to run it due to PROD KYC wall

[Gonals]

It should be! I set the InternalQA flag before merging! (I can't QA it either from Europe 😬)

[francoisl]

Hmm can anyone who reviewed the PR assist with the internal QA steps please?

When I try to pay the request with the account that has no wallet, I only get the Paypal & elsewhere options, even though I have a valid bank account set up.

[MariaHCD]

@francoisl Hmm, I'm assuming that you're on step 4 in the test steps? I think we can just navigate to /enable-payments to get to the AdditionalDetails form since that's the step we need to test here.

[francoisl]

Ok yeah good idea, though in this case I'm hitting this error (which makes sense since the account is not supposed to have a wallet...)

For the record, here's the bankAccountList and userWallet info of the account I'm testing with:

› curl -s 'https://staging.expensify.com/api?command=Get&returnValueList=userWallet,bankAccountList&pretty&authToken='$authToken
{
    "accountID": 957425,
    "authToken": "XXX",
    "bankAccountList": [],
    "email": "XXX",
    "userWallet": {
        "availableBalance": 0,
        "bankAccountID": 0,
        "currentBalance": 0,
        "currentStep": "",
        "tier": -1,
        "tierName": "",
        "walletLinkedAccountID": 0,
        "walletLinkedAccountType": ""
    },
    "httpCode": 200,
    "jsonCode": 200,
    "authResponseMessage": "200 OK",
    "codeRevision": "6c8a1f7d1c5a4016e12e6e8ef068cabe10529477",
    "requestID": "73d503b808e597c7-SJC"
}

@Gonals can you double-check the QA steps are accurate please?

[Gonals]

Hmm. Does the account have a debit card added from oldDot? That's what enabled the option in dev for mine

[MariaHCD]

4. Log into the walletless account and try to pay

I'm not sure this is right, every account has a wallet. In this case, I think we want a wallet that's in the pending state (i.e. not yet KYC'd and activated)

[Gonals]

4. Log into the walletless account and try to pay

I'm not sure this is right, every account has a wallet. In this case, I think we want a wallet that's in the pending state (i.e. not yet KYC'd and activated)

Updated the wording!

[sketchydroide]

@francoisl how is the QA going, just keeping track for the release here

[francoisl]

Still getting the same User has no wallet error from a different account. And I can't add a debit account because my bank will only send a verification code to my US number, and I'm not in the US right now.

That said though, do we really need to make a money request to someone first? Or to simplify, can we just ask someone to navigate to /enable-payments on Newdot staging, and try to fill out the form with an invalid SSN?