New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merge v1.3.8 #4528
Merged
Merged
Merge v1.3.8 #4528
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If we would add DisputeManager to previous structure it would cause a circular dependency error from guice. We change dependency structure so that TradeManager does not know XmrTxProofService but XmrTxProofService gets an instance of TradeManager. It makes code cleaner in total as well as responsibility is better defined. Next commit will contain the DisputeManager addition.
If a mediation or arbitration dispute has been opened we do not use the auto-confirm feature.
- Remove commented out code - do isFiatReceived in stream filter
If users accept visible in mempool only txs its their own risk and they can manually confirm anyway. We should not support 0 conf txs.
- make it xmr orange - make with dynamic with 10 px padding left/right - fix 1 px vertical offset
If --useDevModeHeader is not set it is false by default. If user has --useDevMode=true set it would overwrite his value.
We do not wait until the offer got removed by a network remove message but remove it directly from the offer book. The broadcast gets now bundled and has 2 sec. delay so the removal from the network is a bit slower as it has been before. To avoid that the taker gets confused to see the same offer still in the offerbook we remove it manually. This removal has only local effect. Other trader might see the offer for a few seconds still (but cannot take it).
Might be fraudulent traders.
Support agent can mark a suspicious dispute as resolved so it does not show the alert icon anymore. In the full report a [ACK] got added to that dispute.
For backward compatibility we need to exclude the new field for the contract json. We can remove that after a while when risk that users with pre 1.3.8 version trade with updated users is very low.
We apply userName to accountId if it is not set (e.g. new account created with new version). We do not use that for display or for account signing in case both fields are the same but we need to use accountId in case the user trades with a not updated user who expects accountId as only field. I improved a bit the display of account data in the trade screens. In case accountId was set with the phone number (updated account with phone nr used for account signing) we show both userName and phone nr. - Show phone number if accountId was set by old account. Otherwise show only userName - For old users they will see the user name as phone number displayed if they trade with new users if the new user has created a new account. If he has updated an existing account the accountId (phone number) is used, so it displays the phone number. - At step 2 changed display of own account data to show account name - Add 'Recipients' prefix to account data of peer at step 2 Step 3: Buyers account data can be - Phone number if peer is using old version - User name if peer is updated user with new account (we apply userName to accountId) - Phone number if user is on old version and peer is updated user with updated account (we keep accountId as phone number) - User name/Phone number if peer is updated user with updated account
dispute has been opened. This will cause a Runtime exception but that is justified as the caller need to ensure to do the check and do not allow to get to that point.
…q/desktop/main/portfolio/pendingtrades/steps/seller/SellerStep3View.java
Avoid that a success result overwrites an earlier failed/error result.
The p2pNetworkAndWalletReady MonadicBinding might be removed from GC if its a local variable. I observed that in BisqSetup with a similar setup. It might be an implementation weakness in MonadicBinding (usage of weak references?). A tester reported that he does not see any result, which might be cause that the service never gets the onP2pNetworkAndWalletReady triggered if the MonadicBinding is not there anymore. By removing the listener we need at shutdown we need it anyway as class field (so codacy does not complain anymore). As well added a check if all is already complete to skip the MonadicBinding at all (not expected case in onAllServicesInitialized).
* If Tor *.onion hostname, use HTTP with Tor proxy * If 127.0.0.1 or localhost, use HTTP without Tor proxy * If LAN address or *.local FQDN, use HTTP without Tor proxy * If any other FQDN hostname, use HTTPS with Tor proxy
moment we save the account. Only at that moment we check if we need to set the accountId with the value of the userName. We do that in the domain layer to avoid more domain logic code in the UI layer. Fixes bug found at: #4481 (review)
boring-cyborg
bot
added
in:altcoins
is:no-priority
PR or issue marked with this label is not up for compensation right now
labels
Sep 15, 2020
ripcurlx
changed the title
<!-- - make yourself familiar with the CONTRIBUTING.md if you have not already (https://github.com/bisq-network/bisq/blob/master/CONTRIBUTING.md) - make sure you follow our [coding style guidelines][https://github.com/bisq-network/style/issues) - pick a descriptive title - provide some meaningful PR description below - create the PR - in case you receive a "Change request" and/or a NACK, please react within 30 days. If not, we will close your PR and it can not be up for compensation. - After addressing the change request, __please re-request a review!__ Otherwise we might miss your PR as we tend to only look at pull requests tagged with a "review required". -->
Merge v1.3.8
Sep 15, 2020
….3.8 # Conflicts: # core/src/main/java/bisq/core/support/dispute/agent/MultipleHolderNameDetection.java # core/src/main/java/bisq/core/trade/txproof/xmr/XmrTxProofService.java
sqrrm
approved these changes
Sep 15, 2020
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.