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.
Due to moving the supplier to the variant, we had to add manual search
for producer properties instead of using ransack. So we need a way
for the frontend to diferenciate between product properties and producer
properties. This is the first step towards that
I don't know why, but even though the client sends http accept header for json, rails is treating it as html. This was being overridden in the route, but I want to support multiple formats next. So, we explicitly choose the format by adding it to the request path.
Simple Rails forms prevent double-clicking on submit already. Converting
the StimulusReflex interaction to a simple form submit to a controller
solves the race condition.
The UX is slightly worse because the whole page is reloaded instead
rendering only the connected app panel. But we can solve that when we
add more apps and want to activate them independently. By then, we may
have good patterns for working with Turbo.
Technically, the new buttons are a form within a form which is invalid
HTML, but it works.
We've found that we just can't rely in StimulusReflex (and the underlying WebSockets stack) to guarantee a response to a request.
Because of this, there was intermittent issues when the server was overloaded with large requests, and the response never arrived, leaving an infinite loader, and a poor user wondering if anything was still happening.
This makes testing much easier. But probably also good for users to
revoke any access via OIDC apps. It also enables users to then connect
to a different account, or just renew the current connection.
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.
We were aiming to use stable URLs to identify resources but the URL
helpers were still using dfc-v1.7 because that was the last and
overriding path of the mounted DFC Provider engine.
The generic FeatureToggleConstraint in routing knows about the current
user but not about the enterprise to edit. We could create a new custom
constraint for routing but it's much easier to handle permissions in the
controller. Let's keep routes simple.
(For now at least,) we use one big standard Rails form, and ModelSet to update each record.
Submitting with Reflex allows us to manage the loading state along with the rest of the page (although I would rather use the built in HTTP POST standard).
Aria-label makes it a bit easier for testing (and accessibility software of course!). Technically it should have been aria-labelledby="id_of_column_header" but that would have resulted in more HTML and processing, which seemed silly.
Best viewed with whitespace ignored.
While it's quite common to version APIs it's not possible with current
DFC tools. The architecture also uses URLs as identifiers for objects
like products. Having the id of an object change just because the format
of its description changes doesn't make sense. The DFC may solve this by
adding a version number in a different way.
By removing the version from our API URL, all object ids (URIs) should
be stable from now on.
We were hiding that before because the API is not officially released
yet but that's actually quite annoying. It's very conenient to have the
UI on production and be able to try out endpoints.
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
