- 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.
- added 2 not to be persisted attributes aimed at dealing with the UI
- added them to the permitted list
- updated view to switch mode about on_hand/on_demand
that is: from an already persisted variant or not
- Not persisted deals with on_*_desired not to be persisted fields
- Persisted mode deals with regular on_* fields
- the corresponding spec for both on_hand/on_demand
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.
It should be handled in the controller, it's currently handled in
`Spree::OrderContents#remove`. As long as we don't manually remove line
item from an order we should be good.
Currently it gets trigerred each time the order is saved, which seems to
happen mutiple time when we finalize an order. It's a bit useless to
recalculated the fees over and over
Context, it was added here : 217eda8362
When an admin creates an order, then AmendBackorderJob is called which
can also trigger a new backorder if needed.
This means that we are not creating backorders via subscriptions any
more. It has never been requested and we can bring that back if needed.
The privileges of a user should never change within a request
life cycle. The `spree_roles` association is very small, between 0 and 2
items are quickly searched in memory without the need of additional
database queries.
From memory, I've seen a lot of spree_roles queries in log files per
request. This should reduce it to one.
We have only one role, so let's get rid of the unneeded method.
Now we are in a better place to get rid of Spree::Role and replace it
with a simple boolean.
- if the sheet doesn't have the units present, then the variant is not saved due to model validation
- After that, while assigning on_hand value, error is raised that the variant is not created first
- Now this commit makes sure that the variant is created before implementing above logic
`Spree::OrderContents#update_or_create` is used to update the cart when
on the /shop page. If you start an order and proceed to the "Order
summary" step, and then decide to update your order by using the shop
link next to the cart, such update wouldn't update the shipment.
This result in the order page in the backoffice displaying the wrong data,
and more importantly, in the stock not being updated.
So now we ensure shipment will be updated, which result in the checkout
flow being restarted, thus making sure the shipment is updated.
