This method returns the same thing as the Spree::Order#line_items_adjustments scope, but in a slightly less useful format (an array instead of a relation). The method's name is also totally inaccurate, as currently the only adjustments that appear on line items are tax adjustments for inclusive tax rates, which by definition have no effect on the price whatsoever...
When the user entered a number beyond the stock level, the browser was
correcting that to the max number which is very helpful. But Angular was
setting the model to undefined which removes the item from the cart.
Deactivating Angular's max behaviour let's us set the value ourselves
which is then used in the cart.
If the user entered an invalid quantity, Angular set the model to
undefined and we removed the input field to show the add button. That
makes it impossible for a user to see what the maximum quantity to enter
would be. For example:
- The variant has a stock level of 5.
- The user enters 7.
- Angular sets it to undefined.
- The input field disappears.
- The user is startled and doesn't know how to proceed.
But now we hide the input only if it's deliberately set to zero.
The user can now type anything into the quantity field and some of it
may not be valid. These safe guards ensure that the buttons still work
even if the quantity is undefined or out of range.
Angular guards against the value being out of range but that has other
side-effects. We want to be able to de-activate some of Angular's
behaviour.
It's simpler if there is just one place to add a new product. Closes#6650
This removes the 'creating directly from the new product path' test scenario because we have another 'assigning important attributes' scenario above which provides enough coverage.
We rely now on the exhaustive list of states an order can be in after
checkout. What made this all a bit more messy is that I made up the
"checkout" order state, likely mixing it from the payment model states.
This simplifies things quite a bit and gives meaningful names to things.
We don't care about the conversion from hash to JSON (that's an
ActiveModel::Serializer responsibility that is thoroughly tested) but
our logic so we can skip that step which only slows down tests.
It consistently reduced ~1.5s on my machine but it's still too slow to wait
~8.5s to get feedback from them.
