Request is only send if there isn't another currently running, and also
ensure that filtered enterprise fees are loaded only when not other
request is running.
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.
<button> elements don't inherit font-family from parent by default
in all browsers, causing a visible font mismatch between the
link-based buttons (Back To Store, Back To Website, Cancel Order)
and the button-tag-based Save Changes button on the order
confirmation page.
Add `font-family: inherit` to the base `.button, button` rule so
all button elements use the inherited page font (Roboto). Remove the
now-redundant `font-family: $body-font` from the `.primary` rule.
Fixes#13688
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Add .field class to the email row in the user invitation modal so
the .formError styles (icon, color, font-size) defined in forms.scss
apply consistently with the product list inline errors.
Fixes#13993
I considered a few ways to do this. Cloned products are done with MutationObserver but it doesn't quite sit right with me. A dedicated controller for newly added rows would provide a good general solution. But do we want yet another controller? I'm not sure. This works and is pretty simple (although it requires a quick loop over _every_ form element.. let's see if we can avoid that.)
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.
Preload the allow list once in the controller. This controller was initially set up to avoid instance variables, and pass variables explicitly to the template. That's a good principle, but in practice we have a growing list of variables passed down the chain to multiple partials which is getting cumbersome. I think instance variables have their place after all.
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.
For now, we will only be able to create sourced variant from variants that are visible to us (variants that we manage)
In a later commit I will hide the option if you can't use it
We now include the refunded amount in the email to the customer. When
voiding a payment, it's the full amount of the payment. When giving back
credit then it's only the money that has been paid too much.
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.
