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.
Previously, payment actions that were listed without an associated
`can_?` method were interpreted as supported. All payment methods are
implementing all `can_?` methods for listed actions though. And I think
that new payment methods should explicitely implement all `can_?`
methods instead of relying on this hidden logic.
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.
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.
Although the change fix the issue in the back office scenario, it has
the side effect of getting the order total out of sync. Updating a
payment adjustment need to be followed by udpating the order total and
payment amount to keep everything in sync.
- when update on adjustment in payment, recalculation of
correct adjustment was not done
- the corresponding spec
- an id to easy the finding of the change of fees in the spec
It would take ages to go through all files now and assess all belongs_to
associations. So I just declare the old default and then we can move on
and apply the new default for the application while these classes still
use the old one. All new models will then use the new default which is
the goal of this excercise and we can refactor old classes when we touch
them anyway.
Inspecting 1481 files
...........................................................................................................................................................................................................................................................C..C.CC........................................................................C...C..........C..C..................CC........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
Offenses:
app/models/customer.rb:32:3: C: [Corrected] Rails/ActiveRecordCallbacksOrder: before_validation is supposed to appear before before_destroy.
before_validation :downcase_email
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
app/models/customer.rb:33:3: C: [Corrected] Rails/ActiveRecordCallbacksOrder: before_validation is supposed to appear before before_destroy.
before_validation :empty_code
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
app/models/customer.rb:34:1: C: [Corrected] Layout/EmptyLines: Extra blank line detected.
app/models/customer.rb:49:1: C: [Corrected] Layout/EmptyLines: Extra blank line detected.
app/models/customer.rb:49:3: C: [Corrected] Rails/ActiveRecordCallbacksOrder: before_create is supposed to appear before before_destroy.
before_create :associate_user
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
app/models/enterprise.rb:129:3: C: [Corrected] Rails/ActiveRecordCallbacksOrder: after_create is supposed to appear before after_touch.
after_create :set_default_contact
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
app/models/enterprise.rb:130:3: C: [Corrected] Rails/ActiveRecordCallbacksOrder: after_create is supposed to appear before after_touch.
after_create :relate_to_owners_enterprises
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
app/models/enterprise.rb:133:3: C: [Corrected] Rails/ActiveRecordCallbacksOrder: after_rollback is supposed to appear before after_touch.
after_rollback :restore_permalink
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
app/models/enterprise.rb:134:1: C: [Corrected] Layout/EmptyLines: Extra blank line detected.
app/models/enterprise_group.rb:18:3: C: [Corrected] Rails/ActiveRecordCallbacksOrder: after_save is supposed to appear before after_find.
after_save :unset_undefined_address_fields
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
app/models/enterprise_group.rb:18:3: C: [Corrected] Rails/ActiveRecordCallbacksOrder: before_validation is supposed to appear before after_save.
before_validation :sanitize_permalink
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
app/models/enterprise_group.rb:19:3: C: [Corrected] Rails/ActiveRecordCallbacksOrder: before_validation is supposed to appear before after_find.
before_validation :sanitize_permalink
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
app/models/enterprise_group.rb:23:3: C: [Corrected] Rails/ActiveRecordCallbacksOrder: before_validation is supposed to appear before after_save.
before_validation :sanitize_permalink
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
app/models/enterprise_relationship.rb:15:3: C: [Corrected] Rails/ActiveRecordCallbacksOrder: before_destroy is supposed to appear before after_save.
before_destroy :revoke_all_child_variant_overrides
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
app/models/enterprise_relationship.rb:16:3: C: [Corrected] Rails/ActiveRecordCallbacksOrder: before_destroy is supposed to appear before after_save.
before_destroy :destroy_related_exchanges
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
app/models/spree/order.rb:108:5: C: [Corrected] Rails/ActiveRecordCallbacksOrder: before_save is supposed to appear before before_create.
before_save :update_shipping_fees!, if: :complete?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
app/models/spree/order.rb:109:5: C: [Corrected] Rails/ActiveRecordCallbacksOrder: before_save is supposed to appear before before_create.
before_save :update_payment_fees!, if: :complete?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
app/models/spree/payment.rb:30:5: C: [Corrected] Rails/ActiveRecordCallbacksOrder: after_initialize is supposed to appear before before_create.
after_initialize :build_source
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
app/models/spree/payment.rb:32:5: C: [Corrected] Rails/ActiveRecordCallbacksOrder: after_initialize is supposed to appear before after_create.
after_initialize :build_source
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
app/models/spree/payment.rb:33:5: C: [Corrected] Rails/ActiveRecordCallbacksOrder: after_create is supposed to appear before after_save.
after_create :invalidate_old_payments
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
app/models/spree/payment.rb:34:5: C: [Corrected] Rails/ActiveRecordCallbacksOrder: after_initialize is supposed to appear before after_save.
after_initialize :build_source
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
app/models/spree/payment.rb:35:5: C: [Corrected] Rails/ActiveRecordCallbacksOrder: after_create is supposed to appear before after_save.
after_create :invalidate_old_payments
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
app/models/spree/payment.rb:36:5: C: [Corrected] Rails/ActiveRecordCallbacksOrder: after_initialize is supposed to appear before after_save.
after_initialize :build_source
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
app/models/spree/payment.rb:46:5: C: [Corrected] Rails/ActiveRecordCallbacksOrder: after_initialize is supposed to appear before after_create.
after_initialize :build_source
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
app/models/spree/payment.rb:47:1: C: [Corrected] Layout/EmptyLines: Extra blank line detected.
app/models/spree/product.rb:87:5: C: [Corrected] Rails/ActiveRecordCallbacksOrder: after_create is supposed to appear before after_save.
after_create :ensure_standard_variant
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
app/models/spree/return_authorization.rb:12:5: C: [Corrected] Rails/ActiveRecordCallbacksOrder: before_save is supposed to appear before before_create.
before_save :force_positive_amount
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
app/models/spree/user.rb:49:5: C: [Corrected] Rails/ActiveRecordCallbacksOrder: after_create is supposed to appear before before_destroy.
after_create :associate_customers, :associate_orders
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
app/models/spree/user.rb:50:1: C: [Corrected] Layout/EmptyLines: Extra blank line detected.
app/models/spree/variant.rb:88:5: C: [Corrected] Rails/ActiveRecordCallbacksOrder: after_create is supposed to appear before after_save.
after_create :create_stock_items
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
app/models/spree/variant.rb:89:5: C: [Corrected] Rails/ActiveRecordCallbacksOrder: after_create is supposed to appear before after_save.
after_create :set_position
^^^^^^^^^^^^^^^^^^^^^^^^^^
app/models/spree/variant.rb:90:1: C: [Corrected] Layout/EmptyLines: Extra blank line detected.
app/models/spree/variant.rb:91:1: C: [Corrected] Layout/EmptyLines: Extra blank line detected.
app/models/spree/variant.rb:91:5: C: [Corrected] Rails/ActiveRecordCallbacksOrder: around_destroy is supposed to appear before after_save.
around_destroy :destruction
^^^^^^^^^^^^^^^^^^^^^^^^^^^
app/models/spree/variant.rb:92:1: C: [Corrected] Layout/EmptyLines: Extra blank line detected.
1481 files inspected, 35 offenses detected, 35 offenses corrected
There seems to be some contexts (jobs for subscriptions) where the Payment class loads but LocalizedNumber is an undefined constant. It lives in the /lib directory so it's not auto-loaded.
Looking at prod data; when a checkout submission fails due to something like a card being out of date, the payment's state seems to be "pending" and not "checkout", which means this mechanism fro invalidating old payments is potentially not working where it should.
