Removes the bulk product update feature and its associated components:
- Removes Angular-based bulk product editing controller and views
- Deletes bulk product API endpoints and related controller actions
- Removes product cloning and variant deletion functionality
- Removes associated JavaScript tests and specs
This appears to be part of a larger effort to modernize/simplify the product management interface, removing legacy Angular-based bulk editing in favor of a different approach.
Spree::Admin::UserController is for super admin user only. Moving to a
reflex simplifies the code by getting rid of a new route and a new stimulus
controller
The feature toggle will determine which bulk products screen shows. An additional products_old path is also temporarily added for easy reference.
Later, when the old screen is full removed, we'll probably rename the _v3 classes to tidy up.
There are three main components:
1. The invoice model
2. order serializers: serialize the order for the invoice
3. data presenters: the object that will be use to access the order's serialize data
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.
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
This Spree route conflicts with the one we define:
```
get "/login", to: redirect("/#/login")
```
for whatever reason there are 7 users that managed to hit the Spree one
instead of ours when confirming their signup email. It's not clear to me
though when this `/login?validation=confirmed` is really hit. The
confirmation email link passes a token in the query params and this is
not the case.
The idea is that `GET /login` makes the login modal to show up instead
of Devise's default behaviour (through inheritance) of showing a login
form page. OFN was never prepared to handle this as this bug proofs.
