Fix rounding issues by upgrading decimal maths library

[macanudo527]

What? Why?

BigDecimal was version locked, but with some small modifications to a test and another small modification to display logic, it doesn't need to be. This allows us to use default gems on Alpine Docker images much easier. It also allows dependabot to automatically upgrade the gem when necessary.

What should we test?

• Visit http://localhost:3000/admin/products
• Edit any product's unit to be 500.1, which causes a rounding error.
• Save and verify that the display unit is 500.1 and not 500.09, which happened when we used trunc to create the value instead of round.

Release notes

BigDecimal will now be updated to the latest version more easily.

Changelog Category (reviewers may add a label for the release notes):

• User facing changes
• API changes (V0, V1, DFC or Webhook)
• Technical changes only
• Feature toggled

The title of the pull request will be included in the release notes.

[dacook]

I confess I've never needed to understand numbers at this level! I've added my thoughts, but I think this is ok as it is.

[mkllnk]

Nice one!

I'm glad we have this in a separate pull request now because there's quite a bit to discuss. Awesome work and I think that this update will fix some rounding bugs in our app as well. I just have two little requests to make the code more readable and robust. Otherwise good to go.

[rioug]

Nice, thanks @macanudo527 🙏

[macanudo527]

@mklink is there anything else needed for this one?

[dacook]

Sorry for the delay, as Maikel has been offline for the last week.
I can see that his feedback has been addressed, and this PR has already been added to the testing queue, we are just waiting for someone to verify with manual testing.

[filipefurtad0]

Hey @macanudo527,

Same on my side, apologies for the delay in testing this one.

I think it should close #7504. I've spotted this issue in two places in the app (pics taken before staging):

Products page

Variant edit page

Interestingly, the first test case seems fixed:

While the second one does not:

I've pulled this PR to my local env and tested it locally, but still obtained the same result. I'm very tempted to merge this as it addresses the first test case. Any idea why the second case is not working @macanudo527 ?

Adding the feedback needed label.

[mkllnk]

Sorry, can you add more context? Which number did you enter and which number did you expect? The screenshots on their own look correct to me.

[macanudo527]

@filipefurtad0 I think the numbers in the db will always be a little off due to float inaccuracies, but when you round up they will go away for the display_as value. The only way to eliminate that is to store the sizes as decimals, but I don't think that is necessary.

[filipefurtad0]

@mkllnk @macanudo527, apologies if the pictures are not clear: They relate to two test cases:

• for a L variant, editing the Unit field to be 0.7 -> displays 0.7 as expected, after this PR (before displayed 699.99, issue Inconsistent rounding on some units #7504)

Save and verify that the display unit is 500.1 and not 500.09, which happened when we used trunc to create the value instead of round.

• for a g variant, editing the Unit field to be 500.1 -> should display 500.1, but displays 500.09

I think the numbers in the db will always be a little off due to float inaccuracies, but when you round up they will go away for the display_as value.

Ok, that makes sense. However, I was not expecting that the UI would still display 500.09 after staging the PR. After typing and saving the value or, creating a new variant with the value 500.1, then it is displayed correctly.

Thanks for clarifying, merging!