[$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?

• [x] Android: Native
• [x] Android: mWeb Chrome
• [ ] iOS: Native
• [ ] iOS: mWeb Safari
• [ ] MacOS: Chrome / Safari
• [ ] MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

https://github.com/Expensify/App/assets/78819774/2b2fe875-9b30-4d93-a673-0cf5543f311f

https://github.com/Expensify/App/assets/78819774/ce0183d7-9121-49cd-a40f-e4ff3c847943

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-05-18

Issue Owner

Current Issue Owner: @rayane-djouah

[melvin-bot[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[bot]]

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

[melvin-bot[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.

https://github.com/Expensify/App/blob/90b67a5cd60c86a57b4484847d0b3f30cf2b2430/src/libs/ReportUtils.ts#L6091

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[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[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 https://github.com/Expensify/App/pull/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[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.

[shawnborton]

I can get down with that (third option above), that makes sense to me.

[dannymcclain]

Yup I'm down for option 3 as well. And we definitely already have that pattern elsewhere in the app, so that's cool! You should be able to see it in Storybook (although Storybook isn't working for me anymore...)

[trjExpensify]

Ah yeah, hm.. if we do that will we accidentally implement an infinite loading spinner when offline? That would give the impression we're trying to do something, but we're waiting for you to come back online, so we can do the conversion into the report currency and give you the option to pay the report when it has an updated report total amount.

Pattern C in that regard uses a disabled button I believe, with an offline indicator to explain why that is:

[rayane-djouah]

We can make the button disabled offline and loading online. but, what button should be in loading state? the Submit button or the Settlement button? I think that making the submit button loading makes more sense since the api response that we are waiting on is the SubmitReport request.

So, I think that when we click on the submit button offline it should become disabled, and when online it should shows a loading state, and when we get response from backend, we should display the Settlement button.

What do you think?

[dubielzyk-expensify]

So, I think that when we click on the submit button offline it should become disabled, and when online it should shows a loading state, and when we get response from backend, we should display the Settlement button.

That seems right to me, but keen to hear what @Expensify/design and @trjExpensify thinks about this

[trjExpensify]

I think that making the submit button loading makes more sense since the api response that we are waiting on is the SubmitReport request.

That's not always going to be the case. For example, if you have instant scheduled submit, there's no explicit "submit" function on a workspace, the expenseReport is created in the processing state. Therefore, there would be a Pay settlement button.

So I think we would probably stick to optimistically submit the report when offline as normal and then disable the settlement button, as that works in all cases on the workspace.

[rayane-djouah]

That makes sense. So, I believe the takeaway from this discussion is to show a loading state on the settlement button when online and currency conversion is in progress, and to disable the settlement button when offline to avoid implementing an endless loading spinner. Is that correct?

@shreykul - Can you please update your proposal to accommodate these specifications? Please tag me once it's ready for review.

[melvin-bot[bot]]

@bfitzexpensify @rayane-djouah this issue was created 2 weeks ago. Are we close to approving a proposal? If not, what's blocking us from getting this issue assigned? Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

[rayane-djouah]

Looking for proposals

[shreykul]

@rayane-djouah please check if the proposal is ok and sorry for the late response.

[rayane-djouah]

@shreykul - can you please add more details for technical implementation?

[shreykul]

@rayane-djouah I'm unable to log in to the app whenever I try to click on previous chats it just shows something went wrong.

[rayane-djouah]

@shreykul - Try to pull latest main this may help, and check the browser console to see the error. you can ask for help also in the Slack channel.

[shreykul]

@rayane-djouah, I tried doing that too but I'll check once again.

[melvin-bot[bot]]

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