[HOLD for payment 2024-06-28] [HOLD for payment 2024-06-24] [$250] Android - Scan - Pay elsewhere greyed on submitting expense with currency other than local

[lanitochka17]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 1.4.69
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/4534392
Issue reported by: Applause - Internal Team

Action Performed:

Pre-condition: Workspace set in local currency and submission frequency set to manual

1. Launch app
2. Open Workspace chat
3. Create an expense with local currency
4. Tap submit and pay elsewhere
5. Note paid without any issue
6. Create an expense with currency other than local currency
7. Tap submit
8. Note pay elsewhere button greyed out
9. After tapping greyed out pay elsewhere button few times user able to pay

Expected Result:

In workspace, expense created with currency other than local currency when submitted, greyed out pay elsewhere button must not be displayed

Actual Result:

In workspace, expense created with currency other than local currency when submitted, greyed out pay elsewhere button displayed

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

Record_2024-05-01-22-36-10_4f9154176b47c00da84e32064abf1c48.mp4

Bug6468291_1714591468528.ws.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~0198922fe1d95a1791
• Upwork Job ID: 1786776812730265600
• Last Price Increase: 2024-06-01

Issue Owner

Current Issue Owner: @eVoloshchak / @Christinadobrzyn

Issue Owner

Current Issue Owner: @bfitzexpensify / @Christinadobrzyn

[melvin-bot]

Triggered auto assignment to @bfitzexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[lanitochka17]

@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]

Job added to Upwork: https://www.upwork.com/jobs/~0198922fe1d95a1791

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @rayane-djouah (External)

[shreykul]

Proposal

Please re-state the problem that we are trying to solve in this issue.

The pay elsewhere button is shown as greyed out or disabled when the user selects any other currency instead of the local currency when trying to pay a user.

What is the root cause of that problem?

const canAllowSettlement = ReportUtils.hasUpdatedTotal(moneyRequestReport, policy);

In the above code, there is a condition written in the function "hasUpdatedTotal" which checks if the local currency matches the selected currency if they don't match then the SettlementButton is shown as disabled.

App/src/libs/ReportUtils.ts

Line 6091 in 90b67a5

function hasUpdatedTotal(report: OnyxEntry<Report>, policy: OnyxEntry<Policy>): boolean {

What changes do you think we should make to solve the problem?

As the condition prevents the user from trying to pay before the currency is converted, the condition cannot be removed, instead of removing the condition, we can show the settlement button in a loading state when the currency is being converted and disable the settlement button if the user is offline.

[melvin-bot]

📣 @shreykul! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[shreykul]

Contributor details
Your Expensify account email: shreykulshrestha33@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~01d56d7360118cadc8

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!

[rayane-djouah]

@shreykul, Could you please provide more details on the root cause analysis, including links to the relevant code, and the specific code changes proposed in your solution? This will assist us in better understanding and evaluating your proposal. Also, please utilize the exact proposal template. Kindly update your original proposal and tag me again when it's ready for review.

[shreykul]

Hi @rayane-djouah , Please check if the proposal is okay now...?

[rayane-djouah]

@shreykul, The condition was added in #35062, Can you check why it was added and why it's causing this bug and ensure that removing it will not cause any problem?

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[rayane-djouah]

Bump @shreykul

[shreykul]

@rayane-djouah Sorry, I didn't get the time to read the mentioned issue fully. I'll make sure to update you tomorrow about this issue clearly.

[shreykul]

@rayane-djouah, I've gone through #35062, and it appears that when submitting expenses with currencies other than the local one, the "pay elsewhere" option is being greyed out. This occurs because the currency is first converted to the local currency before enabling the option. The button remains disabled until the converted currency is fetched through the backend.

A similar issue was encountered before, and the solution was to inform the user to wait while the currency is being converted, rather than simply showing the button as disabled. The currency condition cannot be removed because it affects payment calculations when the user is offline, as mentioned in #35062.

To address this, we can implement a toast notification to inform the user why the button is disabled.

[rayane-djouah]

Yeah, It seems that it was decided to implement Pattern C for this case. Therefore, I don't think this is a valid bug.

@Expensify/design - Do you think we need to add a message (like the "You appear offline" message pattern) to inform the user that the currency is being converted?

[dubielzyk-expensify]

After reading the thread and issue I feel like there's a few solutions to this. Ultimately we want the user to wait until the conversion is done and by putting it as disabled it looks like an action is not possible, which isn't the case, it's more that the user needs to wait until they can press the button.

Here's the three solutions I've come up with (though I'm sure there's more):

1. Changing the label of the button while it's converting to Converting... or something similar
2. Replacing the button for a spinner while the conversion is done, then replacing it back to a button
3. Adding a new loading state in our button component that allows for a spinner inside the button while an action is performed (this might be handy for other things in the future too).

Keen to hear what @Expensify/design thinks here. I'm okay with all though option 3 could be useful elsewhere. I've found that a loading state on buttons are handy on other areas of the app where a network request is happening or you tap a button waiting for something but instead of showing a separate loading state you can just change the button state. Open to other solutions too though.

[rayane-djouah]

Great ideas. I think we're using the third option for the login button, it will be good if we make it consistent.

[dubielzyk-expensify]

Oh are we? Awesome find @rayane-djouah!

If so, then that's my vote, but let's hear from @shawnborton and @dannymcclain first.

[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.84-3 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• feat: add loading state to the SettlementButton #42981

If no regressions arise, payment will be issued on 2024-06-24. 🎊

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

• @eVoloshchak requires payment through NewDot Manual Requests
• @kosmydel does not require payment (Contractor)

[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:

• [@eVoloshchak] The PR that introduced the bug has been identified. Link to the PR:
• [@eVoloshchak] 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:
• [@eVoloshchak] 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:
• [@eVoloshchak] Determine if we should create a regression test for this bug.
• [@eVoloshchak] 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 / @Christinadobrzyn] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[melvin-bot]

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

• feat: add loading state to the SettlementButton #42981

If no regressions arise, payment will be issued on 2024-06-28. 🎊

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

• @eVoloshchak requires payment through NewDot Manual Requests
• @kosmydel does not require payment (Contractor)

[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:

• [@eVoloshchak] The PR that introduced the bug has been identified. Link to the PR:
• [@eVoloshchak] 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:
• [@eVoloshchak] 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:
• [@eVoloshchak] Determine if we should create a regression test for this bug.
• [@eVoloshchak] 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 / @Christinadobrzyn] Link the GH issue for creating/updating the regression test once above steps have been agreed upon: https://github.com/Expensify/Expensify/issues/409726

[Christinadobrzyn]

Payouts due:

• Contributor+: $250 @eVoloshchak (thorough NewDot)

@eVoloshchak do we need a regression test?

[Christinadobrzyn]

Payment in a few days

[melvin-bot]

Payment Summary

Upwork Job

• Reviewer: @eVoloshchak owed $250 via NewDot
• Contributor: @kosmydel is from an agency-contributor and not due payment

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/1786776812730265600/hired)
• I have paid out the Upwork contracts or cancelled the ones that are incorrect
• I have verified the payment summary above is correct

[Christinadobrzyn]

This is ready for NewDot payment based on this payment summary - #41445 (comment)

@eVoloshchak let me know about a regression test!

[Christinadobrzyn]

DM'd @eVoloshchak to see about a regression test

[Christinadobrzyn]

going to move this to weekly since the only remaining step is creating a regression test, if needed.

[eVoloshchak]

• The PR that introduced the bug has been identified. Link to the PR: N/A, the behavior wasn't implemented initially
• 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: N/A
• 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: additional discussion isn't needed, the bug is very minor

Regression Test Proposal

1. Go to workspace, press + next to the Composer and "Track expense".
2. Change the currency to a different one than the default one.
3. Typ in an amount and press "Next" -> "Track expense".
4. Veirfy that the settlement button that a loading spinner is shown.
5. Go offline and repeat step 3.
6. Verify that the settlement button is disabled.
7. Go online again and repeat step 3.

Do we agree 👍 or 👎

[Christinadobrzyn]

Thanks @eVoloshchak! Regression test is here - https://github.com/Expensify/Expensify/issues/409726

NewDot payment summary here - #41445 (comment)

Closing as complete!

[JmillsExpensify]

$250 approved for @eVoloshchak based on summary above.