I'm not sure why Arel complained about SQL in the SELECT clause (fields), but not the GROUP BY clause (key_fields). Maybe because it's not susceptible to user injection.
I'm also not sure why I couldn't use the aliases defined in SELECT in the GROUP BY clause, but hey this seems to work.
13220 Fixes affiliate sales spec
13220 Use before_create to update product name
13220 Fixes rubocop warnings
13220 Update product_name in line_item in specs
13220 Fix before_create lint
13220 Add spec for checking product_name is not set in reports
13220 Fixes rubocop issue
13220 Add migrations for updating the existing line items
13220 Fixing lint issues
13220 Set product_name in line_item before doing validation
13220 Fix linter issues
13220 Fixes spec
13220 Fixes linter issues
13220 Review comments
13220 Review comments
13220 Add default product name
13220 Use product_name instead of variant product name when using line item
13220 Fix specs
13220 Revert change in affiliate_sales_data_spec
CL-13220 Store variant name in line_item
13220 Default variant name to original variant's full name for line_items
13220 Add missing frozen string literal
13220 Add spec for full_variant_name
13220 Remove UpdateProductNameInLineItems and AddNotNullToProductNameInLineItems migrations
13220 Remove presence validation for product_name
13220 Use full_product_name which defaults to variant product name if empty
From a comment on Github:
> In this particular case, the spec is broken, actually. I just looked into it and you are right that StripeSCA supports payment profiles but the spec finds that the profile is not stored. And that is because `source.try(:save_requested_by_customer?)` returns false. We only store the profile when the customer is storing their credit card info.
The lastest release wicked pdf does not include a fix to make it
workwith Shakapacker V8 : bce498de54
To we are using our fork for now, which includes said fix
This implicit delegation makes it impossible to know which code is used
and which code is dead. The refund method is very rarely used though. So
we'll need to wait for a while.
The StripeSCA method is forwarding all missing methods to the provider
gateway. The ActiveMerchant gateway used to be decorated by our code and
that's how this code may have worked one day. But we removed the
decorator years ago:
- 549610bc35
A bit later we found that refunds are broken with Stripe:
- https://github.com/openfoodfoundation/openfoodnetwork/issues/12843
This commit could potentiall fix that, I guess? I haven't tested that.
It's a rare use case and not the aim of this work.
StripeSCA is the only method with a different method signature for
`#void` but the additional parameter wasn't used. So this special case
can just be removed.
StripeSCA is the only payment method storing profiles following this
logic. This is the first step to remove indirection and let the payment
method handle this instead of the payment decided for the payment
method.
- 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
This function got renamed in 01d5830480, but this call got missed.
I would like to add a spec to cover this, but am not sure exactly how to set it up right now.
I also notice that usage occurs after the preventDefault, and one before. I'm not sure if that matters. I have myself to blame for that inconsistency 🤦
