I'm not dropping the database table just yet. Let's keep this change
reversible without data loss. And dropping the table would break the
currently running app code during deploy. We can do that another time.
Spree added stock movements to track the movements between stock
locations. But we got rid of stock locations and the only stock
movements we have now are just records of stock level changes.
These records were not created in all cases though and there were also
not created for variant overrides (inventory items). And since these
records aren't visible anywhere, I think it's best we remove them
altogether.
I do think that some kind of log would be useful but I don't think that
AR records like this are the best solution for that. And the
StockMovement model just added complexity to our already complex stock
level storage. The actual adjustment of the count_on_hand attribute of
the StockItem was performed in an after_create hook of the
StockMovement. Now we call it explicitely.
Turns out there seem to be a legitimate use for this code, see
spec/system/admin/adjustments_spec.rb ie, adding a manual discount to an
order using an adjustment.
Remove the code path that can create a tax refund, it is unlikely to
happen with the configuration our instances are using. Instead return 0
do that no adjustment gets created
For payment that complete during the checkout (Paypal, Stripe) the
amount was recorded twice against `order.payment_total`. This is because
the `payment_total` gets updated in an afer_save Payment callback when a
payment is completed, and then once more when we process payment in
`Spree::Order#process_each_payment`.
This is an existing issue on master, but it was hidden by the
`update_shipping_fees!` callback, it trigerred an update of the order's
total, which then updated `order.payment_total` with the correct value.
Now that we removed the callback, the bug showed up.
Note, I updated the stripe specs for consistency even though they are
currently disabled.
