Bug 18186 - Plack config: Amounts with decimal comma instead of decimal dot breaking payments
Summary: Plack config: Amounts with decimal comma instead of decimal dot breaking paym...
Status: In Discussion
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low major (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-03-01 11:16 UTC by Katrin Fischer
Modified: 2023-01-16 04:55 UTC (History)
9 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Katrin Fischer 2017-03-01 11:16:05 UTC
In our current installations running under Plack, the amounts on the pay and paycollect pages suddenly started showing with a decimal comma instead of a decimal point. This causes quite a bit of trouble, as Koha expects a . and amounts entered didn't result in the expected payments. We got several reports about payments being broken in Koha.

Test plan:
- Add manual invoice
- View the "fines" tag
- Verify that individual fees and totals display with , instead of .
- Pay selected or any amount
- Verify that the input field for the amount is also showing the ,
- Verify that paying something like 1,10 doesn't work as expected.

The problem with the test plan is, that you might not see the ,. This appears only on our productions servers, but not in my development environment. 

We tested:
- different language settings in Koha
- different language settings in the browser
- verified that CurrencyFormat isn't used in the code on those page
- verified that all the formatting done was using the TT filter format('%.2f')

In the end the problem turned out to be related to Plack.
Comment 1 Ulrich Kleiber 2017-03-03 09:12:01 UTC
The 'comma problem' started on our production servers after we have enabled Plack. It seems that the CGI version is using locale C whereas Plack is using the default locale of the server. After we have chosen None as our default locale, the decimal point was back again (partly a reboot was required).
Apart from this, the default locale None is also recommended here: https://wiki.debian.org/Locale
Comment 2 Alex Buckley 2017-04-20 04:01:07 UTC
Hi Katrin 

I tried following your test plan doing the following, on the latest version of Koha

* Turning on plack
* Creating a manual invoice with the value 10.00
* Going to the fines tab and observed both the individual fine and the total were displayed with . i.e. 10.00 not a ,

Therefore I am unable to replicate this test plan
Comment 3 Katrin Fischer 2017-04-20 05:34:21 UTC
Hi Alex,
this is not easy to reproduce as it depends on the environment/Plack configuration (see comment from my coworker Ulrich). It's real, but not sure if a patch can be written to fix it. We thought it would be good to write up our finding in case another library runs into this.
Comment 4 Tomás Cohen Arazi 2020-01-24 14:23:51 UTC
So, if you fix some variables:
- browser,
- browser locale
- settings in Koha

then if you switch the locale and restart plack the behaviour change?
Comment 5 Katrin Fischer 2020-01-24 22:01:37 UTC
(In reply to Tomás Cohen Arazi from comment #4)
> So, if you fix some variables:
> - browser,
> - browser locale
> - settings in Koha
> 
> then if you switch the locale and restart plack the behaviour change?

Yes. We have seen this happen twice - we fixed it, we lost the setting in Plack... we fixed it again. I know it sounds strange, we were a bit puzzled as well.
Comment 6 Tomás Cohen Arazi 2020-01-24 22:58:45 UTC
(In reply to Katrin Fischer from comment #5)
> (In reply to Tomás Cohen Arazi from comment #4)
> > So, if you fix some variables:
> > - browser,
> > - browser locale
> > - settings in Koha
> > 
> > then if you switch the locale and restart plack the behaviour change?
> 
> Yes. We have seen this happen twice - we fixed it, we lost the setting in
> Plack... we fixed it again. I know it sounds strange, we were a bit puzzled
> as well.

The only thing I can think of right now is that Plack is smart and imports the env locales settings. And I bet some of our libraries for handling number representations, like TT, is picking that. So we should be hardcoding the 'no-locale' setting.
Comment 7 Katrin Fischer 2020-01-25 18:18:40 UTC
Sounds plausible.