- Sanitize AJAX search queries to safely support wildcard searches (ILIKE)
- Centralize reports search actions in Spree::Ability and reuse across roles
- Fix TomSelect remote loading to fetch on dropdown open and typing
- Surface HTTP errors in TomSelect via showHttpError and improve error handling
- Update dropdown behavior to show proper “no results” feedback
- Move reports AJAX specs to request specs and expand pagination coverage
- Simplify searchable dropdown component attribute passing
It looks like puma finds the file only under `/.well-known/dfc` and not
`/.well-known/dfc/` with a slash in staging environment while it works
here in dev and test.
And in any case, just placing the file in `public/` doesn't produce the
right content type.
It just makes Rswag specs look more different to other request specs and
I found that discouraging. It's good to know that the parameter is just
specified with `let` and that it works exactly in the same way as `let`
in other specs.
The downside is maybe that it's not obvious that those `let` statements
have to correspond with the parameters for the request but error
messages will tell you if you got it wrong. And there's also the
`parameter` declaration to make that clear.
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!
The VINE Api require a secret and an API key to be used. The secret is
used to sign the request. The secret is linked to the API key so we need
to store it along side the key.
This was abandoned when the checkout was re-designed. But I want to
refactor the order locking mechanism and it would be good to know that I
don't break anything.
- implements a turbo response in controller
- display error messages on modal -> able for user to re upload
- removes a pending in spec that now tests error message
We can see on the respective controller spec, that having a Stripe SCA payment, with no source does not trigger the error 400, observed on the legacy checkout.
