Ok so I wasn't as smart as I thought I was. The stimulus controller knows when its element is added/removed from the DOM (and calls connect/disconnect appropriately). But if any child elements are added, they don't automatically have my new event handlers.
So I borrowed jQuery's event delegation concept, and listen for any events that 'bubble' up to the controller element, and delegate them as needed.
Alternatively, maybe I could have used a Mutation Observer, but I think it's best to avoid where possible.
Or of course, we could just revert my change and keep the 'data-action's in the HTML. I'm curious to hear opinions on this.."
I noticed there's a controller for that too, so might as well make use of it. The orders page has it at the top, because that's where the bulk action menu is. But on this page, the action is the import button so I put it there.
We are already specifying the element's role ('all') in the HTML. Its behaviour should be predefined; there's no need to also specify in the HTML.
The eventhandler doesn't need to be cleand up on disconnect, because they are removed along with the DOM object.
- 2 new methods for reading either current/desired on hand/on demand
depending on variant state. Goal is to get rid of send method in View
- referring in on_hand/on_demand is in fact irrelevant. In the piece of
code, only desired on_hand/on_demand can be called as we are only in
new variant (non persisted) mode
- View does not use send method anymore, replaced by current_or_desired
- refactor of the spec -> 2 examples in one to get more speed.
- added 2 not to be persisted attributes aimed at dealing with the UI
- added them to the permitted list
- updated view to switch mode about on_hand/on_demand
that is: from an already persisted variant or not
- Not persisted deals with on_*_desired not to be persisted fields
- Persisted mode deals with regular on_* fields
- the corresponding spec for both on_hand/on_demand
Oh, and a transaction block. Because the controller after hooks tried to update the DB which resulted in
PG::InFailedSqlTransaction: ERROR: current transaction is aborted, commands ignored until end of transaction block
Even for a small rescue statement, it's worth adding a spec. You never know what might not be working!
Tags' rules are still coming from the old admin styles hence had to add
the new (admin_v3) border variable to the old one.
Has a hard coded colour value of #2e3132 as it has no access
to the new colours.
Inputs include custom made ones such as tags, select2s and tom selects.
Some border radii were using mixins but not utilising it, hence they
are now variables.
1. Border colour did not have sufficient contrast. New contrast ratio
passes WCAG AA for Graphical Objects and user interface components.
2. New border variable to aid consistency and future maintanance.
The code was using the code from the environment variables to load a
reocrd from the database to then return the initial code again.
The only use of `DefaultCountry.code` is currently in the geocoder JS
compilation. Now it doesn't need the database anymore.
Turns out there seem to be a legitimate use for this code, see
spec/system/admin/adjustments_spec.rb ie, adding a manual discount to an
order using an adjustment.
Remove the code path that can create a tax refund, it is unlikely to
happen with the configuration our instances are using. Instead return 0
do that no adjustment gets created
