Our production servers don't show any use of this feature. The
associated column is nil for all users.
The gem has not been updated in seven years and it's blocking an
important upgrade of devise.
Taler puts the payment completion into the hands of the user. So we
can't strictly finalise the payment and order together.
And in the bigger picture, it should be okay if a payment goes through
but we have to abort checkout due to stock issues. Then we want to be
able to check out again, using the existing complete payment. Any
refunds can be handled later by the shop owner.
There are two types of linked variant associations: source and target, so we need to keep the name there.
But when cloning a variant and retaining a link as source, we will prefer the general term 'linked variant'. Hopefully this name works well.
I think I was just following convention from existing relationships. Perhaps you could argue that a variant is affected by the links added/removed.. but we never look at updated_at so really there's no point at all.
I tried to avoid it but rubocop made me move it. I think maybe it will need to go into a concern or service class later, but hopefully it's ok here for now.
Co-authored-by: dacook <4188088+dacook@users.noreply.github.com>
Thanks co-pilot for sending me in the right direction.
Would this be neater as a has_and_belongs_to_many? Maybe but I will try to keep moving.
Tried using the rails generator, but as usual it was a waste of time becuase it doesn't handle unusual cases.
I found more good guidance from that stackoverflow post:
> why are you worrying about your indexes? Build your app!
Something's not right in the model, see next commit.
Enterprise have access to the internal payment method by default.
The access is handled at the application level so we don't have to
manage database links.
Add extra security, we don't want to void a credit payment that is not
completed, otherwise we would be refunding credit that was not used.
A credit payment should not be in a non completed state, but you never
know.
It's now called as a before transition callback when the order move to
payment. We need to apply the credit at this point to account for
order fees, ie: shippment fees.
Currently it works like any other payment method you can select on
checkout. It will eventually be added automatically to the order, when a
customer has credit available.
