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.
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.
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
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.
The ReportsController was referencing the report and the report was
referencing the controller. It's unlikely that this circular dependency
created a memory leak but it's generally a bad design. And we need to
make the reporting independent of the controller to isolate it in a
background job.
Controller is constrained by FeatureToggle
- new_products_page
- and available on '/new_products'
Add simple view for new products page and a product
Add new products page as a new entry in the menu
The old Paperclip configuration was very clever and easy to use but it
was also a complicated implementation building on the complicated Spree
preference system.
I simplified this with Active Storage, storing simple references to blob
ids and default URLs as backup.
