When we're fetching the payment intent via PaymentIntentValidator in StripeSCA#purhcase (to capture it), we want it to fail loudly if it's not in "requires_capture" state. We're now also re-using the same PaymentIntentValidator service to check if payment processing was *successful*, in which case we need it *not* to fail loudly if the state == "succeeded", eg != "requires_capture".
The `changed?` method is more accurately replaced by `saved_changes.present?`
In some cases here (where the object had just been saved for the first time) the guard clause was still stopping execution unexpectedly.
#changed? here was not working as before, and the code was never getting past this guard in various places where previously it did. This meant the callback was effectively disabled, and order.update! was not being called when it should be.
As a general rule, if you're triggering an email job as part of an after create/save callback, it should use after commit instead.
Why? The transaction can't finish until after the record is persisted (the data is committed) which includes the logic in all callbacks. So for example if the transaction fails after the email job has been placed it will be rolled back, but the email job will already be in the queue, and it'll be referencing a record that doesn't actually exist (due to the rollback).
This will hopefully let us see in Bugsnag when #6038 happens and so
we'll have all the diagnostics data. The fact that the `order.distributor`
is optional but mandatory to create the customer already gives us some
clue.
The previous permissions assumed that an adjustment's "adjustable" could only be only line items or orders, and that's no longer true. It's now commonly a shipment or a payment as well.
There's no need to create an instance of such class for every call to
one of its methods. The balance is computed each time anyway, so it'll
always be up-to-date.
This keeps the `OrderBalance` abstraction but removes the old code now
that the feature is enabled for all users in all instances and there are
no bugs reported. It's become dead code.
We were also patching ActiveRecord::Relation for the `#find_by_param`
methods but we are not using those any more. They were deprecated a
while ago. We now use `find_by(permalink: ...)`.