Relax CurrencyForm validation to allow for cryptocurrencies

Just give it a fake code, no? Like 999. I don't believe we use that internally. It's just part of the currency data model.

I got a very similar issue when integration the TurlteCoin cryptocurrency into commerce. I also got the problem with the numeric code, but also the currency code "TRTL" does not follow the three characters standard, so I have to improvise here, too. Any plans, ideas or experience to support non-standard currency codes?

Added "Cryptocurrency" to the title for better discoverability.

We should simply drop the 3-letter requirement for currency codes. There is no need to enforce it.

Making numerical codes is harder cause we need to fix that in https://github.com/commerceguys/intl first.

@bojanz Sounds good, but what validation would you suggest instead? As far as I can tell 4 letters are the longest currency codes of cryptocurrencies. So set the validation to 4 characters or something higher for maybe future currencies?

intl does its thing based on the numerical codes?

Retitling.

We'll do the following:
1) Default the numeric code to "000", to allow the form to be submitted without modifying the value.
2) Allow 4-char currency codes.
3) Modify validation to only ensure that the format is uppercase letters.

Here's an initial patch.

Would be great to expand CurrencyTest to test this use case.

Can we think of a better validation error than "The currency code must consist only of uppercase letters." ?

I've added the test with a test for adding a 'Test cryptocurrency' with currencyCode XXXX and the new default numericCode 000.

I don't know a better validation error, and I think it describes it already really well?

Renamed version of #10 so tests can run.

Test fails because 000 != '000', as an int 000 gets converted to 0 and thus fails.

Small update to string the value as well as slightly re-order tests to be more clear, so that save failures will show before the individual validation checks.

I only made minor changes to the tests, so I think it is still ok for me to RTBC this one.

Good catch with the numericCode, is looking good for me now!

Any plans to get this into a release?

Thanks, everyone!

Reverted in https://git.drupalcode.org/project/commerce/commit/2c0d742, due to the conclusions in #3107288: Allow Currency codes which are more than 3 letters (we can't extend the price field storage to support 4-char currencies right now).

If this was reverted it should not be marked as "Closed (fixed)"?

I wanted to add that there is another problem (not just the 3 digit only currency code but also): the numeric code requirement => there are more cryptocurrencies than numbers still available and assigning this number is arbitrary.
I think we should allow an alternative field for at least the BIP44 coin types (see https://github.com/satoshilabs/slips/blob/master/slip-0044.md) that are commonly used by wallets to store/derive the keys for any supported network's currency (native token).

Updating status to match reality. You are free to open a new feature request with a patch, but in general supporting cryptocurrencies is low on our list of priorities.