feat: Don't calculate 100g nutriment if serving_quantity <=5 and value = '0', fixes #5848

[john-gom]

What

Screenshot

Related issue(s) and discussion

• Fixes #[ISSUE NUMBER]

[stephanegigandet]

Today we don't have a way to store "4.0" or "0.0", they are converted to 4 and 0. The API expects numbers for both reading and writing (even though we do support strings for writing).

[john-gom]

Today we don't have a way to store "4.0" or "0.0", they are converted to 4 and 0. The API expects numbers for both reading and writing (even though we do support strings for writing).

Do you anticipate [problem,s with what I am doing here then?

[codecov-commenter]

Codecov Report

Merging #8403 (6e61f97) into main (dbf1da6) will increase coverage by 0.00%.
The diff coverage is 61.53%.

@@           Coverage Diff           @@
##             main    #8403   +/-   ##
=======================================
  Coverage   48.47%   48.47%           
=======================================
  Files         114      114           
  Lines       21277    21286    +9     
  Branches     4770     4772    +2     
=======================================
+ Hits        10314    10319    +5     
- Misses       9679     9682    +3     
- Partials     1284     1285    +1     

Impacted Files	Coverage Δ
lib/ProductOpener/KnowledgePanels.pm	11.51% <0.00%> (-0.11%)	⬇️
tests/unit/food.t	81.29% <75.00%> (-0.19%)	⬇️
lib/ProductOpener/Food.pm	62.60% <100.00%> (+0.12%)	⬆️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[aleene]

Today we don't have a way to store "4.0" or "0.0", they are converted to 4 and 0. The API expects numbers for both reading and writing (even though we do support strings for writing).

The number of digits might imply an accuracy of the value. So 0.5 implies an error of 0.05. And 0.00 an error of 0.005. A kind of implied accuracy.
We could interpret values of < 0.2 as a value of 0 with an error of 0.2. So a separate error-field would be useful.

[stephanegigandet]

Today we don't have a way to store "4.0" or "0.0", they are converted to 4 and 0. The API expects numbers for both reading and writing (even though we do support strings for writing).

Do you anticipate [problem,s with what I am doing here then?

I tried to run it and edit products, but somehow "0.0" is not kept for me. I probably made a mistake somewhere, but I haven't found it yet.

I don't think we should have a field that is always of type number, unless it's "0.0". I think it would be very worthwhile to find a way to keep the extra 0s, but it should be in all numbers (e.g. "4.00").

The function convert_string_to_number() is intended to return a number type, it's used in other functions, so we should be careful if we change its behaviour (probably a new function would be better).

[stephanegigandet]

Perfect, thank you!

The PR is still marked as "draft", can we merge it?

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[stephanegigandet]

Thank you!