You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If the calculator returns a type other than BigDecimal a warning will be issued by the adjustment action for the promotions,
for example create_quantity_adjustments.
I think that we should document this expected interface on the Calculator, and update our actual implementation to respect the expected interface.
I wasn't able to find a test that raises this warning on the Solidus codebase, we should probably add some tests to cover this case.
Solidus Version:
First found out on Solidus 2.5.2.
To Reproduce
Write a test that creates a create_quantity_adjustments using a flat_rate calculator giving in input a nil object.
Launch it.
A Warning should appear in the console about results not being a BigDecimal. ("Spree::Calculator::FlatRate#compute returned 0, it should return a BigDecimal")
Current behavior
Raises a warning when using a standard calculator.
Expected behavior
Doesn't raise any warning when using a standard calculator.
The text was updated successfully, but these errors were encountered:
Hi all, I tested create_quantity_adjustments I added nil object but it is not return 0 either bigdecimal.
this is I got
So, I think as I saw in description it should get back bigdecimal, but It'll not to be, because there exist another class that catching object be nil or not, this is PartialLineItem here
If I'm lost appreciate your help, thanks
The calculator should always return a BigDecimal, but that's not always the case.
For example the flat_rate calculator return 0 as Integer on the else branch.
If the calculator returns a type other than BigDecimal a warning will be issued by the adjustment action for the promotions,
for example create_quantity_adjustments.
I think that we should document this expected interface on the Calculator, and update our actual implementation to respect the expected interface.
I wasn't able to find a test that raises this warning on the Solidus codebase, we should probably add some tests to cover this case.
Solidus Version:
First found out on Solidus 2.5.2.
To Reproduce
Current behavior
Expected behavior
The text was updated successfully, but these errors were encountered: