Bug in PO when creating

David_Douma · February 27, 2024, 10:23am

Hello,

I get a strange bug in the PO that only pops-up in normale users (managers) but not as SuperUser.

I click on Create Purchase Order as Manager and I fill in like below:

And then I click on Next, i get this error:

Blockquote
java.lang.IllegalArgumentException: Multiple decimal separators in pattern “###.###.##0,00”

at java.text.DecimalFormat.applyPattern(DecimalFormat.java:2581)

at java.text.DecimalFormat.<init>(DecimalFormat.java:466)

at gsp_openboxes_purchaseOrder_showOrderItems_gsp$_run_closure2_closure7.doCall(gsp_openboxes_purchaseOrder_showOrderItems_gsp.groovy:133)

at gsp_openboxes_purchaseOrder_showOrderItems_gsp$_run_closure2_closure7.doCall(gsp_openboxes_purchaseOrder_showOrderItems_gsp.groovy)

at gsp_openboxes_purchaseOrder_showOrderItems_gsp$_run_closure2.doCall(gsp_openboxes_purchaseOrder_showOrderItems_gsp.groovy:138)

at gsp_openboxes_purchaseOrder_showOrderItems_gsp$_run_closure2.doCall(gsp_openboxes_purchaseOrder_showOrderItems_gsp.groovy)

at gsp_openboxes_purchaseOrder_showOrderItems_gsp.run(gsp_openboxes_purchaseOrder_showOrderItems_gsp.groovy:352)

at org.pih.warehouse.order.PurchaseOrderController$_closure6.doCall(PurchaseOrderController.groovy:99)

at org.pih.warehouse.order.PurchaseOrderController$_closure6.doCall(PurchaseOrderController.groovy)

at grails.plugin.springcache.web.GrailsFragmentCachingFilter.doFilter(GrailsFragmentCachingFilter.groovy:66)

at net.sf.ehcache.constructs.web.filter.Filter.doFilter(Filter.java:86)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:622)

at java.lang.Thread.run(Thread.java:748)

Blockquote

jmiranda · February 28, 2024, 9:30pm

Interesting. Did you change the default.number.format in any of your supported locales?

By default, it’s defined in messages.properties as

default.number.format=###,###,##0.00

And from what I understand, the default number format pattern should not change. At least, that’s what I’m reading now.

Instead, I guess when you change the locale on any given page, the Grail formatNumber taglib will know that you expect to see the number formatted properly for that locale.

However, I’ll be honest, I don’t actually understand how number formats and locales should work together. For now, reset the default number format (assuming you’ve changed it) and we’ll try to investigate a solution that gives the system a way to parse numbers in a consistent manner while allowing you to display numbers in the format you want.

cc @Artur We should probably create an OBPIH ticket to investigate this. Thoughts?

David_Douma · March 4, 2024, 2:44pm

Hello,

I did not change anything. Where can I check it?

jmiranda · March 5, 2024, 6:50pm

I can think of two places where we could potentially change the default.number.format.

messages.properties (or the locale-specific messages_YY.properties where YY is the locale code)
The localization table (as a superuser you can access this data from Configuration > Localization)

jmiranda · March 5, 2024, 7:02pm

After digging a little more, it looks like the default number format for the Dutch locale uses an “invalid” decimal number format.

github.com

openboxes/openboxes/blob/develop/grails-app/i18n/messages_nl.properties#L485


      
          default.not.updated.message={0} {1} kan niet worden bijgewerkt
          default.not.equal.message=Eigenschap [{0}] van klasse [{1}] met waarde [{2}] kan niet gelijk zijn aan [{3}]
          default.not.found.message={0} niet gevonden met id {1}
          default.not.inlist.message=Eigenschap [{0}] van klasse [{1}] met waarde [{2}] staat niet in de lijst [{3}]
          default.not.unique.message=Eigenschap [{0}] van klasse [{1}] met waarde [{2}] moet uniek zijn
          default.now.label=Nu
          default.notes.label=Notities
          default.null.message=Eigenschap [{0}] van klasse [{1}] kan niet null zijn
          #default.number.format                 = 0
          default.numItems.label=\# items
          default.number.format=\#\#\#.\#\#\#.\#\#0,00
          default.outbound.label=Uitgaand
          default.on.label=op
          default.open.label=Open {0}
          default.openboxes.label=OpenBoxes
          default.optimistic.locking.failure=Een andere gebruiker heeft deze {0} bijgewerkt terwijl u aan het bewerken was
          default.options.label=Opties
          default.origin.label=Oorsprong
          default.other.label=Anderen
          default.paginate.next=Volgende
          default.paginate.prev=Vorige

Ignoring the escape characters, the number format matches what’s included in your initial post.

default.number.format=###.###.##0,00

This is a bug.

For now, we should set this to match the default number format in messages.properties. But we also need to investigate why this happens and how we’re supposed to get around this for all the countries (besides the US and UK) that use this number format pattern.

As a workaround, you should be able to edit the Dutch translations (message_nl.properties under the exploded WAR file within the Tomcat webapps directory) and override the default number format in that file.

For Tomcat 7, that file will likely be found here

/opt/tomcat/webapps/openboxes/WEB-INF/grails-app/i18n/messages_nl.properties

So then change the line

default.number.format=\#\#\#.\#\#\#.\#\#0,00

to

default.number.format=###,###,##0.00

Save the file and restart your application.

NOTE: Any new deployments will likely overwrite this file, so you’ll need to keep updating this until we provide a bug fix in an upcoming release.

Chetan_Maharishi · March 7, 2024, 4:16pm

I can reproduce this error. Here is steps to reproduce this error.

Add supportedLocales ‘nl’ in your application.yml file.
Restart your app
Login with Manager role
Change your locale to Dutch.
Create purchase order.
Once you will save PO, It will redirect to addItems page and there you will see this error.

jmiranda · March 7, 2024, 10:12pm

@Chetan_Maharishi Can you create an OBPIH ticket with this information and mention (@) Manon and me?

Chetan_Maharishi · March 8, 2024, 3:10pm

sure @jmiranda. Creating ticket.

David_Douma · March 9, 2024, 12:59pm

Bumping, what I dont’t understand is:

If I login as a testuser with only Manager and Financial rights I get the error.
If I login as superuser I don’t get the error.

jmiranda · March 12, 2024, 6:23pm

I also do not understand that. It should be included in our bug report so we can investigate further. The only thing that makes sense to me is that you’re using different default locales for each user (testuser uses NL and superuser uses EN). But I assume you’re using NL as well.

David_Douma · March 18, 2024, 1:38pm

So I closed down the error:

If I select English it works when I set the language to Dutch I get the error.
What file could be wrong?

jmiranda · March 18, 2024, 5:43pm

So I closed down the error: If I select English it works when I set the language to Dutch I get the error.

Thank you for the confirmation.

What file could be wrong?

The issue is described in detail in a reply above.

I think the issue was that the original messages_nl.properties file that you sent me contained the default number format that you were hoping to be able to use.

We’ve determined that we cannot use a comma as the decimal separator for the default number format for any locale. And we are still investigating how to allow implementation to use their own number format for displaying numeric values. That probably isn’t going to happen any time soon.

But we have a pull request that we’re hoping to get into the next release (v0.9.1) that fixes the immediate issue that you described in your original post.

In the above reply, I also describe a workaround for fixing the issue locally until we release this (which requires a non-trivial migration process to 0.9.x, which is still being documented).

@Artur For this reason, maybe we should consider this fix for a 0.8.x hotfix as well.

Justin