fix(infocoms): number formatting incompatible with decimal_number option

[MyvTsv]

• I have read the CONTRIBUTING document.
• I have performed a self-review of my code.
• I have added tests that prove my fix is effective or that my feature works.
• This change requires a documentation update.

Description

• It fixes !40061
• This patch resolves a compatibility issue between number formatting and the decimal_number option in the infocoms module.

Screenshots (if appropriate):

decimal_number configuration

Before fix:

After fix:

[trasher]

See comments.

Also, I guess it could be possible to add a test via phpunit to check if displayed value is the one expected.

[MyvTsv]

See comments.

Also, I guess it could be possible to add a test via phpunit to check if displayed value is the one expected.

Does the testFormatNumber function fulfill this requirement for testing the number displayed, or should additional tests be added?

My changes only concern a modification of the Twig macro, because when a field was in the ‘any’ step, the display of the value was not managed by GLPI but by the client.

[Rom1-B]

Does the testFormatNumber function fulfill this requirement for testing the number displayed, or should additional tests be added?

Without your changes, the tests were already passing, so this does not prove that your fix actually resolves anything. You should add test cases that pass with your modification and fail without it to validate its effectiveness.

[cconard96]

👎 From me (obviously not a blocking review)

I maintain the opinion I stated in other PRs that the raw value of an input should not be influenced/formatted by display preferences.
The only places we use decimals_number before now are to display the values from the database as plain text. If the raw input value is set from the result of the user's preferences can we be sure that value is still valid for the input and would still be saved in the database as the raw value? If an item form is loaded with a decimal field set to something like "1.234" but the current decimal preference is 2, the value suddenly becomes "1.23" in the form and saving it will save the truncated value without the user intending to change it.

decimals_number could influence the step attribute in inputs but it should not restrict/change raw values.
The number format preference also should not influence the raw values. Except for the fact so much is rendered on the server, this preference has no place on the server as browsers should show the values in number fields according to the document language (Firefox does. Chrome seems to ignore it).

[cconard96]

Make sure this doesn't cause issues that required the revert in #21123

[trasher]

On the support ticket is said we'll remove the use of the browser native number input; this is probably the best solution - changes currently done in this PR may just be reverted in that case.

[trasher]

See comments

[cedric-anne]

I agree that formating input value is not a good idea. The decimal_number option was initially designed to format values when display on reports, notifications, data tables, search results, ... but not in inputs that should never alter the current value, to be sure that an simple display/save operation will not result in changing the stored value.