SA-2629

Summary

On submit reformats decimal input to use dot as the decimal point.
Comma is standard for locale sv_SE.
------------
Windows SQL Server 2012

- on which browser / version is this behaviour seen?
I have tried Internet Explorer 11 and Chrome version 37. I noticed a difference here: When having Editable format type=Number(see below), we cannot even go forward in Chrome as it will not see it as a decimal value when entering e.g. 10,5. IE OK. But when changing Type to Text it will work in Chrome as well. Notice when coming back to the page it is still the wrong format, i.e. using dot instead of comma.

- how are you setting the user's locale? Is it set in PRPC for the Operator? Or is it set as the Windows control panel Region and Language Format option?
We setting the locale both in OS level and PRPC level.

- what is the data type for this property?
Decimal

Error Messages

N/A

Steps to Reproduce

Same issue for both Text and Number control.

1. Set app server locale to sv_SV.
2. Set operator default locale to sv_SV.
3. Create section that references a decimal type property.
4. Add action “Refresh This Section” on “Change” event.
5. Use this section on a flow action and run a test by creating a work item,
6. set some value to the field containing comma as decimal seperator and click outside, the comma in value changes to dot. And further calculations make this a thousand separator.

Root Cause

PRPC changes the decimal seperator from an entered comma to be a dot on submit of decimal value in Editable format, which then invalidates as 'not a valid decimal value'. Read-only format displays the comma correctly.

Resolution

This issue is resolved by hotfix item HFIX-10208.  Pega 7.1.7 (ML7) will include the full fix.