Therefor, for the right controllers, simply implements:
```
include WhiteLabel
before_action :hide_ofn_navigation, only: [:show, :edit]
```
This is mort robust, since we're working in a controller level, not parsing URLs...
Zones were intended to be sorted by name. But I guess that the syntax of
Ransack changed one day and we didn't notice because the spec was
creating entries in the right order already (which often reflects the
query result order without parameters). So the spec is fixed to fail if
the sorting doesn't happen and Ransack is configured to sort correctly.
The previous sort value was ignored.
Forking worked in theory but crashed the browser in system specs. It
also came with many other hurdles and isn't well known solution in the
Rails community. Sidekiq can give us better control over execution
limits as well.
This check was implemented based on 'allowed' shipping methods, but we need to revert that logic. So for now, we can check all 'available' shipping methods.
This could potentially result in the same query being run twice, because load_shipping_methods also loads it. I opted to keep things simple and not try to optimise here.
When using a "pick up" shipping method, with a user who doesn't have a shipping address it was impossible to proceed to the payment step because shipping address was invalid.
To fix this, we ensure that "ship_address_same_as_billing" parameter is set to true when using a "pick up" shipping method.
use distributor address when shipping method doesn't require a ship address ; in doing this we follow the same logic as the legacy checkout
Allowing creation and deleting via the user association.
It probably won't be much effort to allow editing and multiple records, but I cut it down to the minimum needed to avoid any further delays.
I couldn't find a way to test a failure in the destroy method, but decided to keep the condition because I thought it was worth having.
Change argument for CustomersWithBalance from
enterprise_id to Customers collection.
We have the need to calculate balance for customers in general,
not just for customers in a given enterprise.
Delete now unused code for Angular style bulk orders cancelling
- the Angular controller file
- the bulk_cancel method from controller
- the corresponding entry in route
Enterprises are stored in `@enterprise_set` variables, and we iterate over to show the list of enterprises to super admin.
Previously, we used to use `Sets::EnterpriseSet.new(collection)` instead of creating set based on `@collection`: this leads to call the `collection` method twice, which was probably very time consuming. This commit fix also that.
+ use paginated enterprises loading on bulk update but without testing if the current user is an admin
It's an outdated Spree setting. We always enforce SSL in production and
staging while development and test environments are running without SSL.
This setting didn't have any effect.
Sidekiq doesn't have any features to limit memory usage or execution
time. We need a separate process for this. Forking avoids the boot time
of a fresh process and copy-on-write ensures minimal memory overheads.
This is supposed to lower the memory footprint of all Puma workers. The
reports code will occupy needed memory in one Sidekiq worker instead of
in several Puma processes.
The current code doesn't limit the execution time yet. We either need a
way to terminate the report rendering after a while or send an email
with a link to access a rendered report.
