The previous permissions assumed that an adjustment's "adjustable" could only be only line items or orders, and that's no longer true. It's now commonly a shipment or a payment as well.
This keeps the `OrderBalance` abstraction but removes the old code now
that the feature is enabled for all users in all instances and there are
no bugs reported. It's become dead code.
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.
