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.
- 2 new methods for reading either current/desired on hand/on demand
depending on variant state. Goal is to get rid of send method in View
- referring in on_hand/on_demand is in fact irrelevant. In the piece of
code, only desired on_hand/on_demand can be called as we are only in
new variant (non persisted) mode
- View does not use send method anymore, replaced by current_or_desired
- refactor of the spec -> 2 examples in one to get more speed.
We have only one stock location and that has the default set to false.
Now we can simplify code.
The mentioned Bugsnag notification has not been found. The stock item is
always present in this case but it doesn't hurt to guard against it with
`&.`.
Otherwise we would try to take stock from the producer stock level
without respecting their on-demand settings. So from now on:
If stock level or on_demand are set on the override then it's not using
producer stock levels.
We weren't bothering with stock when items were on demand anyway. But we
want to track stock now so that we can backorder more when local stock
levels become negative.
We weren't bothering with stock when items were on demand anyway. But we
want to track stock now so that we can backorder more when local stock
levels become negative.
In the case where the variant has not been saved yet, we can use #new_record? here instead of #stock_items.empty?, to avoid an additional query. This can be called a vast number of times per request, in various N+1s. The other case where we need to return here is when a variant has been deleted, so #stock_items will be empty and #stock_item will be nil. Likewise, we can just check that with #deleted? and avoid #stock_items.empty?
variant.on_hand will not return infinity any longer if variant.on_demand is true. Clients of these methods will have to handle the combinations between on_hand and on_demand values
