Certain types of adjustments (eg enterprise fees) cannot really be changed arbitrarily; when the order is saved and "recalculated" the values will be reset. The adjustments are still shown in the main order edit tab, but are not editable in the adjustments tab.
We have a PR already that removes the UI for this when the order is
canceled. Implementing it on controller-side makes sure that it doesn't
happen accidentally if the user has multiple tabs open.
This will let us branch by abstraction. All existing calls to
`#outstanding_balance` will go through `OrderBalance` hence, will
check the feature toggle.
Note that by default, `OrderBalance` will end up calling
`#old_outstanding_balance`. As the name states, that's exactly what
`#outstanding_balance` was so far. This means no consumers will see any
change in behavior. We just added on item in the call stack (sort of).
The `Spree::Admin::OrdersController`'s test file quite long (as well as
the controller itself) but it'll grow more in the upcoming commits.
That's just a symptom of that controller having too many
responsibilities. It does much more than CRUD on `Spree::Order` (the
Rails convention).
Things like invoices are an entity on their own and would better fit
into a `InvoicesController`. Hopefully, splitting up the tests is hint
for the next dev to do that.
Setting a tax rate to included fails a validation if a default zone doesn't exist, so that's added. Also improved the tested scenarios and some of the details checked on the updated objects.
BigDecimal was throwing an error here (in Rails 5) unless it received a string, but I think this is actually an issue with the way params were being passed in the relevant spec, as opposed to the controller itself.
This method is named "update distribution charge". What this method actually does is delete all of the fee adjustments on an order and all it's line items, then recreate them all from scratch. We call this from lots of different places all the time, and it's incredibly expensive. It even gets called from inside of transactions being run inside callbacks. Renaming it hopefully will add a bit of clarity.
This needs to be a lot more granular!
