Inconsistent rounding truncates smallest digit for mL units

[filipefurtad0]

Description

Some places in the app are rounding mL units incorrectly.

Expected Behavior

2mL -> should display as 2mL
125mL -> should display as 125mL

Actual Behaviour

2mL -> display as 0mL
125mL -> display as 130mL

Steps to Reproduce

1. Login as admin and create a mL product with unit value of 2
2. Take the necessary steps so it appears on the shopfront
3. As a customer, add this item to the cart and complete an order.
4. Notice the incorrect rounding on the order confirmation screen, summary step table (maybe this error occurs somewhere else as well...)

Animated Gif/Screenshot

For 0.2 mL -> displayed as 0mL:

Checkout Summary Step

Order confirmation Page

For 125 mL -> displayed as 130 mL

Workaround

Reports, shopfront and cart display the correct rounding.

Severity

bug-s3: a feature is broken but there is a workaround

Your Environment

• Version used: v4.6.6
• Browser name and version: all
• Operating System and version (desktop or mobile): all

Possible Fix

See #12787 (comment)

[bouaik]

can i work on this

[sigmundpetersen]

Yes thank you @bouaik , I'll assign you 👍

[bouaik]

The issue is mainly form the wrong calculation of unit_presentation in spree_line_items, is't calculated from final_weight_volume which is a decimal with 2 numbers after the decimal point

Explication of the issue

Also the problem exist for mg units

Notice

I noticed that in line_item model we calculated the unit_value like this
https://github.com/openfoodfoundation/openfoodnetwork/blob/master/app/models/spree/line_item.rb#L224-L228

and the final_weight_volume like this
https://github.com/openfoodfoundation/openfoodnetwork/blob/master/app/models/spree/line_item.rb#L281-L287

Since we already have variant.value in unit_value method, why are we calculating final_weight_volume = variant.value * quantity then getting unit_value = final_weight_volume / quantity ?

Possible fix

I'm suggesting we change the column type to decimal(10, 3) or float if we anticipate smaller units in the future. Also, let's refactor the logic to avoid recalculating unit_value

What do you think guys ?
@rioug

[rioug]

Hi @bouaik,

It makes sense to update the column to decimal(10, 3). As for the calculations , I am sure I am following what you are saying, I'll just point out that the variant.unit_value might change after the line item is created. So that's probably why final_weight_volume is calculated with the variant.unit_value, and also why 'unit_value' is derived from 'final_weight_volume'. But feel free to give it a go if you think it can be refactored.