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 were also patching ActiveRecord::Relation for the `#find_by_param`
methods but we are not using those any more. They were deprecated a
while ago. We now use `find_by(permalink: ...)`.
This guard clause was returning an instance of an unpermitted Params object (containing a blank hash) here, which was causing unexpected results in various places. Returning a blank hash explicitly resolved the issue.
Fixes:
4) Admin::OrderCyclesController create as a manager of a shop when creation is successful returns success: true and a valid edit path
Failure/Error:
@order_cycle_params ||= PermittedAttributes::OrderCycle.new(params).call.
to_h.with_indifferent_access
ActionController::UnfilteredParameters:
unable to convert unpermitted parameters to hash
# ./app/controllers/admin/order_cycles_controller.rb:245:in `order_cycle_params'
# ./app/controllers/admin/order_cycles_controller.rb:44:in `create'
# ./spec/support/controller_requests_helper.rb:49:in `process_action_with_route'
# ./spec/support/controller_requests_helper.rb:27:in `spree_post'
# ./spec/controllers/admin/order_cycles_controller_spec.rb:124:in `block (5 levels) in <module:Admin>'
Leaving the object with unpersisted changes breaks order locking with this error (in various places):
RuntimeError:
Locking a record with unpersisted changes is not supported. Use `save` to persist the changes, or `reload` to discard them explicitly.
- As VariantUnitManager.variantUnitOptions() returns array formatted like this: `"Weight (g)", "weight_1"` and `product.variant_unit_scale` is formatted like this `weight_1.0` there is no possible match for the <select /> element
- So, remove the trailing `.0` from `product.variant_unit_scale` to match the options
Rails 5.2 has changed the way initializers are called during certain rake tasks including `db:create`. Initializers that were previously not loaded are now loaded (basically the whole app is loaded). This means any calls to #table_exists? that appear in the app will throw fatal errors as the database doesn't exist yet during that task, but those calls are made before `db:create` has even started, which means the database can't be created.
There are also a few other places in Spree code where #table_exists? is called, and they already call #connected? first to guard against this issue.
