[Bug]-[1336]:Decimal operator doesn't work for values that have none zero decimals

[narhzih]

Is there an existing issue for this?

• I have searched the existing issues

Description

When there's a currency input, using values like 100.00 or anything.00 works, but then it's greater than .00 (e.g., .01, .02, or .12), it throws an error saying "Please use. " as the decimal separator for default values."

Steps To Reproduce

1. Use a currency input
2. Use a number like 100.15 (non-zero decimal)

Public Sample App

No response

Environment

Production

Issue video log

No response

Version

Cloud & Self - Hosted 1.9.9

[dilippitchika]

Few details to note to triage this issue

1. This happens when the locale/region is brazil where decimals are represented with commas
2. This should have been fixed in here but it wasn't- [Enhancement]-[84]:Currency widget should allow , to be used as decimal seperator #14261

[ashit-rath]

Stats

Stat	Values
Reach	334
Effort (months)	0.5

[dilippitchika]

@rajatagrawal can you check this out?

[rajatagrawal]

Hello @narhzih,

Thank you for reaching out to us.

As per the repro steps mentioned by you, we are unable to repro the issue on the latest version of Appsmith. Attaching a loom video that demonstrates the same.

If you think that I have missed something, please let us know. Closing the issue otherwise.

https://www.loom.com/share/1cc6244037c241be92abf3205a888d1c

[rajatagrawal]

Did you mean that localization for default value property in the property pane for currency widget instead ? @narhzih.

Reopening the issue.

[rajatagrawal]

Loom video of issue with default value property field : https://www.loom.com/share/5cf9ab8d07884e2088edb69f4f2ed255

[somangshu]

cc @dilippitchika @rajatagrawal this is still a part of the sprint, are we planning to work on it?

[rajatagrawal]

yes, I will be working on this in this sprint.

[rajatagrawal]

@somangshu

[rajatagrawal]

Had a dicussion with @keyurparalkar and @dilippitchika .

Notes from discussion

We would need to handle cases where the values are stored in DB in . format and would be needed to be converted to ',' format if they are used in the default value validation field if localization is applied.

There are many other similar corner cases that need to be handled for having localization in default column. So, by design the default value only supports '.' as the decimal separator. We assume that a user does not use , as thousands separator because otherwise the value will get parsed as a string.

This issue is not a bug but more of a feature which would be a part of a bigger localization project. Thus, we can work on this issue only if it is a critical.

Moving it out of the sprint for now.

cc : @somangshu