Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Pricing conversions with non-US user.language and user.region do not work in the admin #1079

Closed
phillipuniverse opened this issue Aug 15, 2014 · 1 comment
Closed

Pricing conversions with non-US user.language and user.region do not work in the admin #1079

phillipuniverse opened this issue Aug 15, 2014 · 1 comment
Assignees
@phillipuniverse
Labels
severity-major type-bug
Milestone
3.0.14-GA

Comments

@phillipuniverse
Copy link
Contributor

This was originally reported and fixed in 3.0.6-GA and 3.1.2-GA in #542 but has reappeared in 3.0.10-GA and 3.1.2-GA in order to fix #698. Need to get with @jefffischer to talk about next steps in how both of these fixes can coexist.

Marking as a major bug as it prevents correct locale parsing in the admin.
@phillipuniverse phillipuniverse added this to the 3.0.14-GA milestone Aug 15, 2014
@phillipuniverse phillipuniverse self-assigned this Aug 15, 2014
@phillipuniverse phillipuniverse mentioned this issue Aug 15, 2014
Closed
@phillipuniverse phillipuniverse changed the title Pricing conversion problem after starting tomcat with custom user.language and user.region values Pricing conversions with non-US user.language and user.region do not work in the admin Aug 15, 2014
@phillipuniverse phillipuniverse mentioned this issue Aug 26, 2014
Closed
phillipuniverse added a commit that referenced this issue Sep 21, 2014
@phillipuniverse
#1079 - Go back to parsing decimal values in the admin via the Decim…
0d37e62 
…alFormatter

Revert "Revert: Fixes #542 - Be consistent about how currencies are displayed and parsed in the admin. Also fall back to the default Java locale when there is no default Broadleaf locale set in the database (70acd44)"

This reverts commit 0130ae0.
phillipuniverse added a commit that referenced this issue Sep 21, 2014
@phillipuniverse
Fixes #1079 - Validate that the entire decimal string is parsed when …
cd50918 
…saving a decimal or money value in the admin when validating
phillipuniverse added a commit that referenced this issue Sep 21, 2014
@phillipuniverse
#1079 - Ensure that the value being shown in the admin form for decim…
a29c634 
…al values has the correct decimal separator (like commas for the French locale). Also ensure that the OOB admin decimal formatter does not use grouping so that larger numbers are displayed correctly
@phillipuniverse
Copy link
Contributor Author

I put back the DecimalFormat code but added extra validation for a ParsePosition. This will ensure that the entire string value was parsed. For instance, when parsing 12.9g9 the parse position of that string will be 4 rather than 6 (the entire length of the string). This way we can throw a validation problem if they have any non-number/-decimal characters in the submitted string.

phillipuniverse referenced this issue Nov 20, 2014
@phillipuniverse
Fixes #397 - Change the admin numeric input types to text as Chrome w…
6b7dd31 
…ill submit a blank string to the server if there is a non-numeric value
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@phillipuniverse phillipuniverse

Labels
severity-major type-bug
Projects
None yet
Milestone
3.0.14-GA
Development

No branches or pull requests
1 participant
@phillipuniverse