You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add contributions you have delivered and roles you have performed here as new rows in the table below. Role line-items should include an asterisk (*) in the team column.
The getoffers api doesn't return any offers until the user has created his payment accounts. Afterward the api will only return offers that the user can take. This behavior is confusing and frustrating for new developers. The new behavior is to show all offers for a given market (direction, currency) by default.
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
bisq: Always show ARS blue rate popup (account creation)
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.
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.
bisq: Fix crash due to broken filter provided nodes merge
The filter provided nodes were added to a read-only List and this lead to crashes at start-up. We didn't catch the bug before because the lists in the tests are mutable. Now the FederatedBtcNodeProvider.getNodes method operates on Streams.
bisq: Refactor baseCurrencyNetwork field to getter access
The persistingBlockInProgress field is read by the block parsing thread. However, the block parsing thread and user thread write to the persistingBlockInProgress field. The block parsing thread might see the update too late and trigger another snapshot before the previous was done.
The parseBlockCompleteAfterBatchProcessing field is set on the block parsing thread and read by Jersey's HTTP threads. By default, Jersey handles requests synchronous on multiple threads.
PR Review (for v1.9.19): Do not navigate to open offers after user has clicked dont show again
This PR is incomplete and handles only single currency payment accounts. Therefore, the popup won't show when ARS is selected in multi-currency payment accounts. Apart from that, the ARS popup is shown after the user created his payment accounts. I opened several PRs to improve usability. The new behavior is to show the ARS popup when the user selects ARS or it gets auto-selected during payment account creation. Additionally, we show the ARS popup when the user selects it as a currency in Bisq (offerbook, trade charts, trade statistics, and preferences). All popups except the ones during payment account creation have a "Don't show again" checkbox.
PR Review (for v1.9.19): Only show XMR subaddress recommendation if the user has a XMR account setup
I fixed a NullPointerException, broken URLs, and improved the behaviour in follow up PRs. Now we show the XMR subaddress if the user has a non-subaddress XMR account and when the user creates a new XMR account.
Summary
6048.39
Contributions delivered
utACK
utACK
utACK
The getoffers api doesn't return any offers until the user has created
his payment accounts. Afterward the api will only return offers that the
user can take. This behavior is confusing and frustrating for new
developers. The new behavior is to show all offers for a given market
(direction, currency) by default.
Changes:
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:
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.
Changes:
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.
The filter provided nodes were added to a read-only List and this lead
to crashes at start-up. We didn't catch the bug before because the lists
in the tests are mutable. Now the FederatedBtcNodeProvider.getNodes
method operates on Streams.
The parseBlockCompleteAfterBatchProcessing field is set on the block
parsing thread and read by Jersey's HTTP threads. By default, Jersey
handles requests synchronous on multiple threads.
The text was updated successfully, but these errors were encountered: