At closer inspection, almost all logic around which payment actions to
display involves only the state of the payment. So I moved the logic
there.
We now have one list of all possible actions supported by the UX. Then
payment methods can declare a list of supported actions. If that's
conditional, they can implement the conditions themselves. The payment
model itself then still filters the actions based on its state.
We currently ask the credit card first which payment actions like "void"
it supports. But all the logic is not card specifc. It depends on the
payment method which actions it supports.
And instead of having two different classes potentially being the source
of truth for actions, I prefer leaving that responsibility with exactly
one class, the payment method.
I'll move the `can_?` methods next.
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.
We had an old version under "contested settings" and it looks like some
of them were modified. I hope that our new, separate file will
discourage manual tweaks.
We can include the relaxed rules from a gem as well. Let's see if we
need that complexity one day.
It's now just called `mode`. This avoids the warning:
../app/models/spree/gateway.rb:31:in `provider': Base#gateway_mode is deprecated in favor of Base#mode and will be removed in a future version
