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.
The comment about falling back to the default locale came from the first
commit, when the config was just `fallbacks = true`. The fallback logic
is a lot more sophisticated now and we can supply the country's default
locale as first fallback and our source locale `en` as last resort. It
should contain everything.
In the future, we may want to support maps like Canadian French can fall
back to original French. I18n supports this but providing the config per
isntance may be a bit tricky.
The locale config is set in application.rb from environment variables
already. We don't need to repeat that logic in test.rb. And because it
was outdated, the language switcher was actually broken in the test
environment. We did have an English selector for the fallback `en` even
though we were already displaying English as en_TST. And after
switchting to Spanish, we could switch back because en_TST was not in
the available locales.
I now fixed the test with the right assumption and the config to solve
the problem.
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.
The permission is effectively the feature toggle. Users can choose to use it, but shouldn't expect it all to work perfectly yet.
When it's considered full featured, we just need to update the translation. Hm... I hope that's not too painful.🤞
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
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.
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.
