Workspace - User can save the wrong rate

[kbecciv]

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

---

Issue found when executing PR #18454

Action Performed:

1. Go to URL https://staging.new.expensify.com/
2. Login with any account
3. Go to Settings > Workspace > choose or create a workspace >Reimburse expenses
4. Change the rate and the unit
5. Check that you can't save a wrong rate: 1. or 0.

Expected Result:

User can't save a wrong rate.

Actual Result:

User can save the wrong rate.

Workaround:

Unknown

Platforms:

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

• Android / native
• Android / Chrome
• iOS / native
• iOS / Safari
• MacOS / Chrome / Safari
• MacOS / Desktop

Version Number: 1.3.19.1

Reproducible in staging?: Yes

Reproducible in production?: new feature

If this was caught during regression testing, add the test name, ID and link from TestRail:

Email or phone of affected tester (no customers):

Logs: https://stackoverflow.com/c/expensify/questions/4856

Notes/Photos/Videos: Any additional supporting documentation

https://platform.applause.com/services/links/v1/external/0468af9dd4ab6d9c43ab952bf3538f97905dcc92d1b02aed1627473ed50852f4

Expensify/Expensify Issue URL:

Issue reported by: Applause - Internal Team

Slack conversation:

View all open jobs on GitHub

[melvin-bot]

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

[melvin-bot]

Bug0 Triage Checklist (Main S/O)

• This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• This bug is not a duplicate report (check E/App issues and #expensify-bugs)
  • If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
• This bug is reproducible using the reproduction steps in the OP. S/O
  • If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
  • If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
• This issue is filled out as thoroughly and clearly as possible
  • Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
• I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[trjExpensify]

👋 @youssef-lr @eVoloshchak @ShogunFire @joelbettner looks like a regression from this PR, is it on your radar to fix as this is only on staging right now?

[ShogunFire]

@trjExpensify I can make the correction right now but I don't know the process for regressions. Do I just need to do another PR ?

[trjExpensify]

Yup, let's do another PR right away. @youssef-lr @joelbettner @eVoloshchak if you guys agree this is a deploy blocker, let's add the label too.

[eVoloshchak]

Huh, I remember testing this case specifically and thinking 1. or 7. is a valid input and this is effectively the same as calling .trim() for a string. We've got all the information we need from the user, we should interfere as little as possible.
And that's how it was implemented previously (currently on prod).
But I could see how it can be considered invalid, this might be an indication that the user mistyped the rate, so let's spin up PR with the fix

@trjExpensify, I don't know what qualifies to be a deploy blocker (is there a doc?) but this seems very minor to be a deploy blocker

[trjExpensify]

And that's how it was implemented previously (currently on prod).

Ah, so if it was already on prod then it's not a deploy blocker, so it was right not to add the label on this 👍

[trjExpensify]

This hit prod yesterday and it was a follow-up PR from the other issue, so I'm going to just close this out now.