We were already eventually removing the "success" border style on
inputs. I think it makes sense to do the same for the success message
itself. That's how our standard "flash messages" already work.
This is pretty black magic to me, but my understanding is that:
* When submitting customer forms, we use `$q.all()` on the result of
submitting each form asynchronously in order to decide whether to
display a success message (no errors) or a failure message.
* The value returned for each particular form submission was the return
value of either `change.scope.success()` or `change.scope.error()`.
These use the `switchClass` factory, which changes a particular DOM
element's class to the proper pending/success/error class, but in the
success case, it also sets a timeout to remove the class using
`$timeout()`, which is a promise, and that was its return value.
* Because of the above, `$q.all()` was actually waiting for the
`$timeout()` promise to be fulfilled before proceeding.
The fix is to not return a `$timeout()` promise from the `switchClass`
factory when a timeout is passed, but instead set a timeout on the
element, but return the element itself regardless.
* Keep save bar visible as long as there's a customer form displayed.
* Only display "You have unsaved changes" when there's any difference
from the original values. If form changes are reverted, hide that
note.
* Similarly, only let the button be enabled if there are any actual
changes to be saved.
This link would go to the enterprise edit screen, but didn't successfully select the payment methods panel.
Ideally, the spec would try to follow the link and verify that you can see the Connect with Stripe button. But it opens the link in a new tab and I'm not sure how to test that.
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.
Moves search field configuration from frontend to backend to prevent potential security issues with exposing internal field names. The change also improves maintainability by centralizing search logic in the controller.
Adds conditional logic to use name_alias for non-admin users when searching distributor names, enhancing data access control.
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.
