Changed all references of processable_image to processable_file which was a breaking change from v1 to v2 https://github.com/igorkasyanchuk/active_storage_validations/tree/3.0.2?tab=readme-ov-file#upgrading-from-1x-to-2x
Also it upgraded the way of validating files from just the file name and content type, so tests also needed to change for file upload checks
Refactored all the similar file image validator content type in Spree::Image::ACCEPTED_CONTENT_TYPES and Updated ImageBuilder.import method to use the url.path when getting filename.
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.
They don't actually show up when the customer is saved, but the next
time the page is reloaded. We already have the save bar for the same
purpose so it's not necessary.
* 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.
With a product with mutiple variant, we can end in a scenario where a
user sees variant associated to producer it doesn't have permission for.
This prevents the user from updating any variant. This fix filter out
variant a user shoudn't be seeing
variant_tag feature check should happen per enterprise basis, but we
still want super admin to so see variant tag. To do so we check if the
user is amdin or if any of the current user enterprise has variant tag
enable.
