Before PR #7123, we showed the XMR subaddress popup whenever the user
naviated to the account tab. After PR #7123, we show the XMR subaddress
popup if the user has an XMR account. However, it's better show the
popup if the user has a non-subaddress XMR account.
It's hard for the seller to read the buyer's account details because the
string is long, e.g, "Account owner name (first, middle, and initial of
last name): Alice A., Mobile no. +71234567890, Bank name SBP Bank".
I shortened "Account owner name (first, middle, and initial of last
name)" to "Account owner name".
Recent changes broke reproducibility and the last release's JAR_HASH
file contains "Dummy file (needed for updater)". We need to keep
creating a dummy file because the updater fails without a dummy file.
This change fixes the bug.
We show the ARS blue rate popup whenever the user creates a payment
method and ARS is selected. Therefore, it makes sense to always show the
ARS blue rate popup.
At the moment, we show the ARS Blue Rate popup when the user saves a
single currency payment account (PR #7122). This misses many payment
accounts that support ARS. The new behaviour is to show the ARS Blue
Rate popup when ARS is selected during account generation (either
pre-selected or later selected by the user).
Payment accounts supporting ARS:
- CashByMail
- CashDeposit
- F2F
- MoneyGram
- National bank
- OKPayAccount (deprecated)
- Same bank
- Specific bank
- Transferwise
- Uphold
- Western Union
Code Review follow-up - Remove substition replacements for strings which
do not have any substition parameters, as these are causing confusion as
to whether apostrophes are required.
When clicking Create Buy/Sell Offer, or Edit/Duplicate/Clone an existing
offer, randomly the initial display of "Currency" associated with the
initially selected payment method was displayed as blank. This seems to
have been caused by scheduling the selection of the initial payment
method combobox selection to happen on a different thread rather than
immediately selecting it (apparently, sometimes the secondard event to
select the currency gets lost).
Added new displayStrings into other language files as a placeholder for
future translation, minor revision to order of payment method fields
in source code (cosmetic, no impact on functionality)
This is the standard P2P payment method in Russia to perform funds transfers and
payments between Russian bank accounts in Russian Rubles. There is no chargeback
risk. Recipient bank account is located using telephone number and bank name,
and sender receives recipients first name, middle name, and initial of last name
to confirm the phone number entered is correct before sending. Adding this new
payment method has been discussed at length on the GitHub 'growth' channel at:
https://github.com/bisq-network/growth/issues/288
Created new class PhoneNumberRequiredLengths.java with a Map lookup for the
requiredlength of phone numbers in select countries that are well-known to
have uniform fixed-length phone number throughout. Country codes missing
will continue to use just the previous length-range algorithms. Lookup
into this Map is integrated into PhoneNumberValidator.java, no longer
needed an overloaded constructor to provide this functionality.
[New .java file was accidentally omitted from previous commit]
Created new class PhoneNumberRequiredLengths.java with a Map lookup for the
requiredlength of phone numbers in select countries that are well-known to
have uniform fixed-length phone number throughout. Country codes missing
will continue to use just the previous length-range algorithms. Lookup
into this Map is integrated into PhoneNumberValidator.java, no longer
needed an overloaded constructor to provide this functionality.
Original commit omitted the new display string used by this new
feature. Additionally, added two unittests to verify the code
changes in this pull request work and do not break existing
functionality.
