Add protection tools to offer #5051
Closed
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
14 tasks
CloseConnectionMessage as it would trigger a wrong log on the peers side, that he got banned.
The numbers did not match up from delivered response size and items as we did not count in the overhead of the ProtectedStorageEntry (pub key+sig) and did estimate the size with taking only first item and multiplying it. A measurement resulted in 20 ms costs for the exact calculation (toProtoMessage().getSerializedSize() has some costs). I guess that is acceptable to get correct metrics.
currencies as TransferWise supports sending to most currencies.
…of the users accounts. Default value is false, so same behaviour as before the change. If no payment account is setup then we also show all payment methods. In that case (no payment account) we disable the toggle as well as set it to false.
Use isShowAllEntry methods instead of equals checks
We cannot add a field to OfferPayload as we use the hash for signing and any change would break compatibility between diff. versions. We also cannot rename one of the un-used fields as we use json for creating the contract hash and that would fail in the trade then.
Calls from the API set the flag to true, from the desktop its false. If offer has denyApiUser enabled the offer availibility check fails. @ghubstan: I set the value in CoreApi and not directly in the CoreTradesService, so keep it more open that those sub domain classes can be used from desktop as well. Not sure if is not intended/permitted for some reason but I though that way we have more flexibility. Feel free to remove the param and set it directly in CoreTradesService if that class will never be used from non-api code.
Extract to OfferFilter method. Use enums for return values so the view can show the matching popups.
@ghubstan: If the `offerFilter.canTakeOffer` call can be included into `getOffers(String direction, String currencyCode)` and maybe also in `getOffer(String id)` we can remove the `getOffersAvailableForTaker` method.
flag instead. If we would store the flag in the offer we would need to update all offers if the preferences flag changes.
I would not make sense that the API user has set the preferences to not accept API taker for their offers. This was from the older version where we used the offer to carry the flag. @ghubstan Api user cannot see if an maker has set the flag but will receive an error at offer availibility check.
chimp1984
force-pushed
the
add-protection-tools-to-offer
branch
from
8447a6c to
c68c0ed
Compare
Merged
|
Replaced by #5053 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Implements protection tools in context of API deployment (bisq-network/projects#46)
Based on #5045, #5038
Will merge master and rebase once those are merged so commits are easier to review...