A fee can be associated to both the incoming and outgoing exchange, the
previous logic did not account for that, resulting in the fee not being
correctly removed.
Now the delete logic also check for the metadata enterprise role to see
if any additional fee need to be removed.
We now update or create line item fees instead of deleting them and
recreating them. This is to cover the case when a product has been
removed from an Order Cycle but we want to keep the fee already applied
on existing order. This was an issue only if the existing order got
updated after the product was removed.
We now update or create line item fees instead of deleting them and
recreating them. This is to cover the case when a product has been
removed from an Order Cycle but we want to keep the fee already applied
on existing order. This was an issue only if the existing order got
updated after the product was removed.
When importing another catalog, it's probably referring to external
product groups. Storing the external link allows us to group several
variants and replicate the same structure within OFN.
- 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
