[HOLD for Payment 5-16][$250] Distance rate - Value ending with decimal point in distance rate editor is not accepted

[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.65-5
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
Issue reported by: Applause - Internal Team

Action Performed:

1. Go to staging.new.expensify.com
2. Go to FAB > Submit expense > Manual
3. Enter amount ending with decimal point (eg, 8.) > Next
4. Note that app proceeds to next step
5. Go to taxes section in Collect workspace
6. Click Add rate > Value
7. Enter amount ending with decimal point (eg, 8.) > Save
8. Note that the value is accepted
9. Go to Distance rates section > Add rate
10. Enter amount ending with decimal point (eg, 8.) > Save

Expected Result:

The value ending with decimal point in distance rate editor should be accepted

Actual Result:

The value ending with decimal point in distance rate editor is not accepted

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

Bug6460730_1713988278794.20240425_034651.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~010c566adc64c516d8
• Upwork Job ID: 1783752626404245504
• Last Price Increase: 2024-04-26
• Automatic offers:
• ikevin127 | Reviewer | 0
• GandalfGwaihir | Contributor | 0

[melvin-bot]

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

We think that this bug might be related to #wave-collect - Release 1

[lanitochka17]

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

[allgandalf]

Proposal

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

Validation fails for values with only decimal pointer and no digits after that.

What is the root cause of that problem?

For distance rates, We have a validation function which calls validateRateValue:

App/src/pages/workspace/distanceRates/CreateDistanceRatePage.tsx

Line 45 in 9a727de

(values: FormOnyxValues<typeof ONYXKEYS.FORMS.POLICY_CREATE_DISTANCE_RATE_FORM>) => validateRateValue(values, currency, toLocaleDigit),

This validation function has a regex which doesn't allow us to have a value with only decimal point and no digit after that, this causes the validation logic to fail:

App/src/libs/PolicyDistanceRatesUtils.ts

Line 18 in 9a727de

const rateValueRegex = RegExp(String.raw`^-?\d{0,8}([${getPermittedDecimalSeparator(decimalSeparator)}]\d{1,${CurrencyUtils.getCurrencyDecimals(currency) + 1}})?$`, 'i');

Note: Same doesn't happen with tax, we allow the user to enter only decimal point in tax, so we should fix it here.

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

We need to update the regex to:

const rateValueRegex = RegExp(String.raw`^-?\d{0,8}([${getPermittedDecimalSeparator(decimalSeparator)}]\d{0,${CurrencyUtils.getCurrencyDecimals(currency) + 1}})?$`, 'i');

Well update {1, to {0, after the decimal separator part, allowing for zero or more digits after the decimal point.

What alternative solutions did you explore? (Optional)

We also need to update the edit page as well, the bug occurs there too.

[Christinadobrzyn]

I think this might be vsb-split (as I see other BZ Distance GHs linked to that project). Let's see if this can be external

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~010c566adc64c516d8

[melvin-bot]

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

[Christinadobrzyn]

However, I'm also wondering if we want to fix this as explained in the OP or if we want to throw an error. Do we want users to be able to enter a "3." value?

Asking the team what we want as an expected behaviour - https://expensify.slack.com/archives/C05RECHFBEW/p1714115140280529