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 happened back in 2015 through
9c9051498b, but two places were missed.
One was a code comment so did not affect anything (other than confused
code readers I guess?). The other one did create a regression but was
later fixed by 18d966f0de in 2021.
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.
This PR fixes issue #13272 where supplier and product names containing HTML character entities (e.g. ã) were rendered as raw text on the /admin/inventory page.
For example, a supplier name intended to appear as:
Pãtes du Contentin
would incorrectly display as:
Pãtes du Contentin
Cause:
AngularJS’s {{ ... }} interpolation inserts raw strings into the DOM without decoding HTML entities.
There is no easy way to share template between AngularJS and Rails. The
modal in `edit.html.haml` is a copy of app/assets/javascripts/templates/out_of_stock.html.haml,
so we need to update both if either of them is updated.
