[$250] Inconsistent Currency Code Representation for 'MRO' in LHN

[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: 9.0.13-3 Reproducible in staging?: Y Reproducible in production?: Y If this was caught during regression testing, add the test name, ID and link from TestRail: N/A Email or phone of affected tester (no customers): betlihemasfaw14@gmail.com Issue reported by: Applause - Internal Team

Action Performed:

1. Go to Account Settings > Workspace
2. Change the default currency to 'MRO' in Profile
3. In the LHN, go to Workspace Chat > Plus Sign > Expense Request
4. Add a merchant and confirm it
5. Go to IOU and observe the LHN

Expected Result:

The currency code should be consistently represented as 'MRO' throughout the app

Actual Result:

The currency code is inconsistently represented as 'UM' instead of 'MRO' when submitting an expense and viewing the IOU in LHN

Workaround:

Unknown

Platforms:

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

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

Screenshots/Videos

Add any screenshot/video evidence

https://github.com/user-attachments/assets/52b0ef9f-605d-41f3-82a7-de78213a9477

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~019389c6893f847c12
• Upwork Job ID: 1817710932397878288
• Last Price Increase: 2024-08-04

Issue Owner

Current Issue Owner: @mollfpr

[melvin-bot[bot]]

Triggered auto assignment to @jliexpensify (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]

@jliexpensify 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/~019389c6893f847c12

[melvin-bot[bot]]

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

[daledah]

Proposal

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

The currency code is inconsistently represented as 'UM' instead of 'MRO' when submitting an expense and viewing the IOU in LHN

What is the root cause of that problem?

The polifill for Intl.NumberFormat we're using does not have the correct symbol value of MRO, example in https://github.com/formatjs/formatjs/blob/f71ce48aaf8ada6a77d393d3f2293fc14f2c38c2/packages/intl-numberformat/test262-main.ts#L1019.

Perhaps it's because MRO is a retired currency and no longer in use since 2018, so no longer actively supported. Meanwhile back-end library still returns currency symbol as MU, hence the inconsistency.

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

Remove the retired currencies from the list of currencies in the app, namely here https://github.com/Expensify/App/blob/main/tests/unit/currencyList.json#L1 and here https://github.com/Expensify/App/blob/98d8a5ae4bb52539669f79e007246417eb8c8f1e/src/CONST.ts#L4512 because no user will use it (or should be allowed to use it)

Or, do not remove the currency completely but filtering out the retired currencies when displaying select options for the user (like in the currency list for submitting expense), this will allow user to view retired currencies in legacy reports/transactions, but not able to create new reports/transactions with retired currencies.

We can also hide it only if the retired currency is not currently selected (if it's already selected in previous requests, the user should be able to view the (maybe disabled) selection when clicking on the currency button, if the user selects another currency however, they won't be able to select the retired currency again.

What alternative solutions did you explore? (Optional)

• Fix the symbol value in the @formatjs/intl-numberformat (there and in other places where symbol is set to MRO) to the correct value UM then update the lib version in our app, or we can create a patch. This seems to happen to other similar currencies too, such as "MRU" so might worth updating them too
• In https://github.com/Expensify/App/blob/98d8a5ae4bb52539669f79e007246417eb8c8f1e/src/libs/NumberFormatUtils/intlPolyfill.ts#L1, init the same polyfill as in iOS https://github.com/Expensify/App/blob/98d8a5ae4bb52539669f79e007246417eb8c8f1e/src/libs/NumberFormatUtils/intlPolyfill.ios.ts#L7, because we'd need the polyfill for all platforms for the above currency cases

Another solution could be that: Replace the currency formatting logic in the front-end by whatever is used in the back-end, so they are consistent.

[melvin-bot[bot]]

@mollfpr, @jliexpensify Whoops! This issue is 2 days overdue. Let's get this updated quick!

[mollfpr]

Will review the proposal in the morning!

[jliexpensify]

Thank you @mollfpr

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

[mollfpr]

This issue is on the BE where it returns the lastMessageHtml or lastMessageText with UM currency. As mentioned in the proposal the currency MRU is also set as UM in the LHN's last message but the exchange is different between MRO and MRU.

@jliexpensify We might need an internal engineer to check why the report sends a different currency for the lastMessageHtml and lastMessageText values.

[daledah]

@mollfpr The back-end returned data is correct. UM is the symbol representation of MRO (the code here).

UM in lastMessageHtml or lastMessageText is correct, just like $ is used in those places instead of USD.

The bug is in the front-end as explained in my proposal, it should show UM throughout just like $ is shown around the app.

[mollfpr]

Okay, I understand now. It's correct that MRO is obsolete.

The currency code is inconsistently represented as 'UM' instead of 'MRO' when submitting an expense and viewing the IOU in LHN

@daledah @jliexpensify I think the actual result is expected where UM is a symbol representing currency MRO.

[jliexpensify]

Thanks for the investigation @mollfpr - if MRO is now obsolete, could we just change it to MRU or even UM in-product? I think if we can get rid of the inconsistency, that would be good.

if it's not something that can be fixed, then we can close this one.

[daledah]

I think if we can get rid of the inconsistency, that would be good.

@jliexpensify The inconsistency can be fixed in the front-end using my proposal (both main and alternative solution)

@mollfpr Could you kindly review the proposal? Thx!

[mollfpr]

if MRO is now obsolete, could we just change it to MRU or even UM in-product? I think if we can get rid of the inconsistency, that would be good.

@jliexpensify We can filter out the obsolete currencies mentioned in the @daledah proposal.

[jliexpensify]

Ok, I think we could probably fix this then? @mollfpr want to push it forward and we'll get an Internal Engineer to make the final decision?

[mollfpr]

The actual issue here is expected that UM is the symbol for MRO currency, but it's mentioned in the @daledah proposal we have obsolete currency (including MRO which replace by MRU) I think it's a better chance to filter them out from the list.

🎀 👀 🎀 C+ reviewed!

[melvin-bot[bot]]

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

[melvin-bot[bot]]

@youssef-lr @mollfpr @jliexpensify 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!

[jliexpensify]

Bumping @youssef-lr to review proposal, thanks!

[melvin-bot[bot]]

@youssef-lr, @mollfpr, @jliexpensify Eep! 4 days overdue now. Issues have feelings too...

[jliexpensify]

Bumping @youssef-lr to review the proposal, cheers!

[melvin-bot[bot]]

@youssef-lr, @mollfpr, @jliexpensify Still overdue 6 days?! Let's take care of this!

[jliexpensify]

DM-ed Youssef for a review.

[melvin-bot[bot]]

📣 @daledah You have been assigned to this job! Please apply to the Upwork job and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review 🧑‍💻 Once you apply to this job, your Upwork ID will be stored and you will be automatically hired for future jobs! Keep in mind: Code of Conduct | Contributing 📖

[daledah]

@mollfpr This PR is ready for review.

[melvin-bot[bot]]

This issue has not been updated in over 15 days. @youssef-lr, @mollfpr, @jliexpensify, @daledah eroding to Monthly issue.

P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

[jliexpensify]

Checked PR, this is deployed to staging but not to prod.

[mollfpr]

@jliexpensify The PR is deployed to production 3 weeks ago. I think Melvin failed to send the notification. https://github.com/Expensify/App/issues/48035

[mollfpr]

[@mollfpr] The PR that introduced the bug has been identified. Link to the PR: [@mollfpr] 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:

No offending PR.

[@mollfpr] 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:

The regression step should be enough.

[@mollfpr] Determine if we should create a regression test for this bug. [@mollfpr] 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.

1. Select FAB > Submit expense 2 .Open Select currency list
2. Verify that: Retired currencies (such as MRO) is not shown anymore
3. 👍 or 👎

[jliexpensify]

Dang ok - thanks @mollfpr!

[jliexpensify]

Payment Summary

• C: @daledah $250 - can you please add your Upworks name to your GH profile so I can hire you?
• C+: @mollfpr $250 (ND Payment)

Upworks job - https://www.upwork.com/jobs/~021836326350630574505

[daledah]

Hey @jliexpensify here's my Upwork profile link https://www.upwork.com/freelancers/~0138d999529f34d33f

TIA

[jliexpensify]

Thanks @daledah - offer sent

[garrettmknight]

$250 approved for @mollfpr

[jliexpensify]

Paid and job closed!