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
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
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
And let the OFN app decide under which name to mount the DFC engine.
It simplifies the code and will make it more flexible to introduce other
versions in the future.
