[HOLD for payment 2024-04-09] [Simplified Collect][Workflows] Bank account info still displayed in Make or track payments after disconnecting

[kavimuru]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Version Number: 1.4.51-1
Reproducible in staging?: y
Reproducible in production?: unable to check in production
If this was caught during regression testing, add the test name, ID and link from TestRail: n/a
Logs: https://stackoverflow.com/c/expensify/questions/4856
Issue reported by: applause internal team
Slack conversation:

Action Performed:

precondition: user created a paid policy in OD and added a bank account

1. Go to https://staging.new.expensify.com/
   and log in
2. Select the paid policy workspace in the workspace switcher > Settings
3. Click on Workflow
4. Enable Make or track payments toggle
5. Select Bank account
6. Click on the Bank account option > Disconnect

Expected Result:

The bank account information disappears, and "Connect bank account" is displayed

Actual Result:

The bank account information is still displayed even after refreshing the page. Also, after disconnecting the bank account, toggling off/on the "Make or track payments" option, and clicking on bank account the disconnected bank account shows up.

Workaround:

unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

Bug6411594_1710279276937.Recording__282.mp4

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @bfitzexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[kavimuru]

@bfitzexpensify FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors.

[melvin-bot]

Triggered auto assignment to @robertjchen (Engineering), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[kavimuru]

We think this bug might be related to #wave-collect - Release cc @trjExpensify

[trjExpensify]

This is related to the workflows project, yeah. CC: @lakchote

[luacmartins]

cc @ishpaul777 since you worked on the implementation of this feature

[ishpaul777]

Okay i will handle this 👍

[ishpaul777]

Okay so we can reset the ${ONYXKEYS.REIMBURSEMENT_ACCOUNT}${policyID} in onyx when we call resetFreePlanBankAccount like this:

 {
                    onyxMethod: Onyx.METHOD.MERGE,
                    key: `${ONYXKEYS.REIMBURSEMENT_ACCOUNT}${policyID}`,
                    value: {
                        isLoading: true,
                        pendingAction: CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE,
                        achData: null,
                    },
}

but how will the cross device sync work? do we need any backend change here to update @luacmartins

[luacmartins]

Oh we might actually handle this as part of #37680, when we clean up the current VBBA keys and use the new reimbursementAccount<policyID> format.

@nkuoch could you please confirm if changing resetFreePlanBankAccount to use ${ONYXKEYS.REIMBURSEMENT_ACCOUNT}${policyID} instead of ONYXKEYS.REIMBURSEMENT_ACCOUNT is currently in that issue's scope?

[nkuoch]

Let me take it over. I've actually decided not to use ${ONYXKEYS.REIMBURSEMENT_ACCOUNT}${policyID} anymore. I'll give a better update in a bit.

[getusha]

@nkuoch could you assign me here, for C+ role? thanks

[trjExpensify]

Looks like all the PRs are done here, amazing! Payment will be needed for @getusha on #38395. It hit staging 4 days ago, so the regression period clock should start soon after the next deploy.

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 1.4.58-8 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• Use policy achAccount instead of reimbursementAccount in WorkspaceWorkflow #38395

If no regressions arise, payment will be issued on 2024-04-09. 🎊

For reference, here are some details about the assignees on this issue:

• @getusha requires payment (Needs manual offer from BZ)

[melvin-bot]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [@getusha] The PR that introduced the bug has been identified. Link to the PR:
• [@getusha] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
• [@getusha] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
• [@getusha] Determine if we should create a regression test for this bug.
• [@getusha] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [@bfitzexpensify] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[bfitzexpensify]

@nkuoch mind taking a look at #39439?

[melvin-bot]

Payment Summary

Upwork Job

• ROLE: @getusha paid $(AMOUNT) via Upwork (LINK)

BugZero Checklist (@bfitzexpensify)

• I have verified the correct assignees and roles are listed above and updated the neccesary manual offers
• I have verified that there are no duplicate or incorrect contracts on Upwork for this job (https://www.upwork.com/ab/applicants//hired)
• I have paid out the Upwork contracts or cancelled the ones that are incorrect
• I have verified the payment summary above is correct

[bfitzexpensify]

Offer sent @getusha

[getusha]

@bfitzexpensify accepted

[bfitzexpensify]

Payment complete. I don't think a regression test is necessary here. Let's close this out.