-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[$250] Inconsistent Currency Code Representation for 'MRO' in LHN #46392
Comments
Triggered auto assignment to @jliexpensify ( |
@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 |
Job added to Upwork: https://www.upwork.com/jobs/~019389c6893f847c12 |
Triggered auto assignment to Contributor-plus team member for initial proposal review - @mollfpr ( |
ProposalPlease 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 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 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 Line 4512 in 98d8a5a
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)
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. |
@mollfpr, @jliexpensify Whoops! This issue is 2 days overdue. Let's get this updated quick! |
Will review the proposal in the morning! |
Thank you @mollfpr |
📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸 |
This issue is on the BE where it returns the @jliexpensify We might need an internal engineer to check why the report sends a different currency for the |
@mollfpr The back-end returned data is correct.
The bug is in the front-end as explained in my proposal, it should show |
Okay, I understand now. It's correct that MRO is obsolete.
@daledah @jliexpensify I think the actual result is expected where UM is a symbol representing currency MRO. |
Thanks for the investigation @mollfpr - if if it's not something that can be fixed, then we can close this one. |
@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! |
@jliexpensify We can filter out the obsolete currencies mentioned in the @daledah proposal. |
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? |
@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! |
Bumping @youssef-lr to review proposal, thanks! |
@youssef-lr, @mollfpr, @jliexpensify Eep! 4 days overdue now. Issues have feelings too... |
Bumping @youssef-lr to review the proposal, cheers! |
@youssef-lr, @mollfpr, @jliexpensify Still overdue 6 days?! Let's take care of this! |
DM-ed Youssef for a review. |
📣 @daledah You have been assigned to this job! |
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! |
Checked PR, this is deployed to staging but not to prod. |
@jliexpensify The PR is deployed to production 3 weeks ago. I think Melvin failed to send the notification. #48035 |
No offending PR.
The regression step should be enough.
|
Dang ok - thanks @mollfpr! |
Payment Summary
Upworks job - https://www.upwork.com/jobs/~021836326350630574505 |
Hey @jliexpensify here's my Upwork profile link https://www.upwork.com/freelancers/~0138d999529f34d33f TIA |
Thanks @daledah - offer sent |
$250 approved for @mollfpr |
Paid and job closed! |
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: 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): [email protected]
Issue reported by: Applause - Internal Team
Action Performed:
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?
Screenshots/Videos
Add any screenshot/video evidence
Bug6551142_1721786074503.Screen_Recording_2024-07-23_at_6.31.01_PM.mp4
View all open jobs on GitHub
Upwork Automation - Do Not Edit
Issue Owner
Current Issue Owner: @mollfprThe text was updated successfully, but these errors were encountered: