infocoms not updated - incorrect decimal value
Closed this issue · 10 comments
Code of Conduct
- I agree to follow this project's Code of Conduct
Is there an existing issue for this?
- I have searched the existing issues
Version
10.0.20
Bug description
Hi,
Since the update to the latest version 10.0.20 I cannot update any infocom anymore. Also, the value field is empty even though there is a value in the DB.
In sql.log I see errors saying there's an incorrect decimal value.
Relevant log output
[2025-09-13 14:19:34] glpisqllog.ERROR: DBmysql::doQuery() in /volume1/web/glpi/src/DBmysql.php line 395
*** MySQL query error:
SQL: UPDATE `glpi_infocoms` SET `use_date` = '2025-09-13', `value` = '', `warranty_value` = '', `date_mod` = '2025-09-13 14:19:34' WHERE `id` = '426'
Error: Incorrect decimal value: '' for column `glpi`.`glpi_infocoms`.`value` at row 1
Backtrace :
src/DBmysql.php:1499 DBmysql->doQuery()
src/CommonDBTM.php:686 DBmysql->update()
src/CommonDBTM.php:1703 CommonDBTM->updateInDB()
front/infocom.form.php:69 CommonDBTM->update()
public/index.php:82 require()
{"user":"6@ds1823"}
[2025-09-15 10:22:42] glpisqllog.ERROR: DBmysql::doQuery() in /volume1/web/glpi/src/DBmysql.php line 395
*** MySQL query error:
SQL: UPDATE `glpi_infocoms` SET `delivery_date` = '2024-06-17', `use_date` = '2024-06-17', `value` = '', `warranty_value` = '', `warranty_date` = '2024-06-17', `date_mod` = '2025-09-15 10:22:42' WHERE `id` = '377'
Error: Incorrect decimal value: '' for column `glpi`.`glpi_infocoms`.`value` at row 1
Backtrace :
src/DBmysql.php:1499 DBmysql->doQuery()
src/CommonDBTM.php:686 DBmysql->update()
src/CommonDBTM.php:1703 CommonDBTM->updateInDB()
front/infocom.form.php:69 CommonDBTM->update()
public/index.php:82 require()
{"user":"6@ds1823"}Page URL
No response
Steps To reproduce
- In General Settings > Default values. Change the Number format to "1 234,56".
- Create any object and financial information
- Try to update and save.
Your GLPI setup information
No response
Anything else?
No response
I do not reproduce. Try without any plugins.
Thanks for your quick response. I tried it with all plugins deactivated, still the same issue.
Any idea how to debug and what to check?
Thanks
I found a way to reproduce.
In General Settings > Default values. Change the Number format to "1 234,56".
Then the error occurs.
I can confirm the bug.
When I set the number format to 1234.56, the entries are saved again. If I reset the format to 1234,56, none of the fields in infocoms are saved.
I put here my last 2 comments of #21067, as they could clarify the problem:
glpisqllog.ERROR: DBmysql::doQuery() in /var/www/html/glpi/src/DBmysql.php line 395
*** MySQL query error:
SQL: UPDATE glpi_infocoms SET value = '', warranty_value = '', comment = 'Prueba', date_mod = '2025-09-19 10:52:27' WHERE id = '489433'
Error: Incorrect decimal value: '' for column glpi.glpi_infocoms.value at row 1
Backtrace :
src/DBmysql.php:1499 DBmysql->doQuery()
src/CommonDBTM.php:686 DBmysql->update()
src/CommonDBTM.php:1703 CommonDBTM->updateInDB()
front/infocom.form.php:69 CommonDBTM->update()
{"user":"8@GLPI-corporate.intranet.beep"}
I have put a 0 in the field 'value', the SQL error was then on 'warranty_value'.
If I put a 0 in both value and warranty_value, the text I add in "comment" is saved correctly.
Note in my case the fields value and waranty:value where initially blanks.
I confirm the issue using chromium browser. No problem with Firefox. Seems related to usage of input/@type=number and GLPI number formatting - no idea why and how to fix (I guess the problem may appear elsewhere)
I confirm the issue using chromium browser. No problem with Firefox. Seems related to usage of
input/@type=numberand GLPI number formatting - no idea why and how to fix (I guess the problem may appear elsewhere)
Just revert this commit of yours: 1b9f387
Or limit this to 2 digits after the decimal separator.
Here is what we experienced on our instance. We mainly uses Chrome and the browser locale are EN and FR depending on the users. I put 53566 in Value and save the asset, successfully. When the page is reloaded, with this commit (v10.0.20), the page will attempt to display "53 566.00" in a input/@type=number, which is invalid.
Without this commit, the number is displayed as '53566.0000'. It's a little ugly but it's working.
As mentioned in the MDN (https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/number), such inputs are not expected to beautifully display numbers but only to strictly validate numbers.
Incidentally, Mozilla's own browser is not validating correctly this field: https://bugzilla.mozilla.org/show_bug.cgi?id=1398528
I confirm what LordVeovis says: quitting "|formatted_number" for these 2 lines does solve the problem.
About #20918 the commit 1b9f387 was supposed to fix:
I tracked down this "formatted_number" to be mapped to getFormattedNumber in DataHelpersExtension.php, which directly calls Html::formatNumber.
The real formating is done in Html::formatNumber but it does not exposes $edit and there is no $decimal exposed either.
If $edit is exposed, that would allow to override the number format as defined in $_SESSION['glpinumber_format'] so the format is respected when input is of type number from the template.
If $decimal is exposed, that would allow to control the number of decimal for some specific fields also from the template. Exposing this, (and in fine removing the $decimal = $CFG_GLPI["decimal_number"]; from this function tool) would allow different number to have different decimal. If for €, I am expecting 2 decimals, for kg I can expect 3 decimals.
Allowing formatted_number to have arguments may be done with variadic filters if I am reading this correctly.