-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Add rpc method 'getoffers' #4329
Conversation
This change fixes the ambiguity in the original class name, which implied it was a btc wallet service, not a bsq and btc wallets service.
This commit includes the following changes: * New tests for methods `lockwallet`, `unlockwallet`, `removewalletpassword`, and `setwalletpassword`. * New `getbalance` method error handing tests to verify error message correctness when wallet is locked. * Update to `getversion` method test -- now expects `1.3.4`. * Check for new `[params]` column header in help text.
This addresses task #1 in issue bisq-network#4257. This new gRPC WalletService method displays the BTC wallet's list of receiving addresses. The balance and number of confirmations for the most recent transaction is displayed to the right of each address. Instead of returning a gRPC data structure to the client, the service method returns a formatted String. If the BTC wallet has no unused addresses, one will be created and included in the returned list, and it can be used to fund the wallet. The new method required injection of the BtcWalletService into CoreWalletsService, and the usual boilerplate changes to grpc.proto, CliMain, and GrpcWalletService. Some of the next PRs (for bisq-network#4257) will require some common functionality within CoreWalletsService, so these additional changes were included: * a private, class level formatSatoshis function * a public getNumConfirmationsForMostRecentTransaction method * a public getAddressBalance method * a private getAddressEntry method A unit test that verifies a successful return status was added to cli/test.sh.
Cleaned up the method body and improved the returned string's formatting. Also added a line for this method in the CLI help text.
This addresses task 2 in issue 4257 bisq-network#4257 This new gRPC Wallet service method displays the balance and number of confimirmations of the most recent transaction for the given BTC wallet address. The new method required the usual boilerplate changes to grpc.proto, CliMain, and GrpcWalletService. Two unit tests to check error msgs was added to cli/test.sh.
This addresses task 4 in issue 4257. bisq-network#4257 This PR should be reviewed/merged after PR 4304. bisq-network#4304 This new gRPC PaymentAccounts service method creates a dummy PerfectMoney payment account for the given name, number and fiat currency code, as part of the required "simplest possible trading API" (for demo). An implementation supporting all payment methods is not in the scope. Changes specific to the new rpc method implementation follow: * New createpaymentacct method + help text was added to CliMain. Help text formatting was also changed to make room for larger method names and argument lists. * The PaymentAccount proto service def was renamed PaymentAccounts to avoid a name collision, and the new rpc CreatePaymentAccount was made part of the newly named PaymentAccounts service def. * New GrpcPaymentAccountsService (gRPC boilerplate) and CorePaymentAccountsService (method implementations) classes were added. * The gRPC GetPaymentAccountsService stub was moved from GrpcServer to the new GrpcPaymentAccountsService class, and GrpcPaymentAccountsService is injected into GrpcServer. * A new createpaymentacct unit test was added to the bats test suite (checks for successful return status code). Maybe bit out of scope, some small changes were made towards making sure the entire API is defined in CoreApi, which is used as a pass-through object to the new CorePaymentAccountsService. In the next PR, similar refactoring will be done to make CoreApi the pass-through object for all of the existing CoreWalletsService methods. (CoreWalletsService will be injected into CoreApi.) In the future, all Grpc*Service implementations will call core services through CoreApi, for the sake of consistency.
This change is a refactoring of the gRPC Wallets service for the purpose of making CoreApi the entry point to all core implementations. These changes should have been made in PR 4295. See bisq-network#4295 The gRPC Wallet proto def name was changed to Wallets because this service manages BSQ and BTC wallets, and GrpcWalletService was changed to GrpcWalletsService for the same reason. This PR should be reviewed/merged after PR 4308. See bisq-network#4308 This PR's branch was created from the PR 4308 branch.
Response to comment in PR 4299: bisq-network#4299 (comment) This PR should be reviewed/merged after PR 4309. bisq-network#4309
Refactor getFundingAddresses to use memoization
Also reordered some import statements according to Bisq style rules.
This addresses task 5 in issue 4257 bisq-network#4257 This new gRPC PaymentAccounts service method displays the user's saved payment accounts. A unit test to check a successful return status code was added to cli/test.sh. This PR should be reviewed/merged after PR 4322. bisq-network#4322
The 'getaddressbalance' and 'getfundingaddresses' methods now send new AddressBalanceInfo proto messages instead of a formatted String to the client. The AddressBalanceInfo message contains addressString, balance, and # of confirmations (transaction confidence) fields. Changes include: * A new AddressBalanceInfo proto message * A wrapper class for the new AddressBalanceInfo proto * New 'getaddressbalance' and 'getfundingaddresses' signatures in server * AddressBalanceInfo display logic in client * Removal of balance formatting logic in server * Refactoring of balance formatting logic in client
This is not in scope of current PR, but easy enough to review.
This reverts commit bfcc693. This change was reverted because we want unexpected Exceptions to bubble up for now, until CorePaymentAccountsService.java throws specific IllegalStateExceptions with user friendly error messages. (See CoreWalletsService.java for example.)
The previous revert was a mistake. It applied to GrpcPaymentAccountsService, not CorePaymentAccountsService.
Remove the recently added gRPC StatusRuntimeException wrapping logic because we want unexpected Exceptions to bubble up for now, until CorePaymentAccountsService.java throws specific IllegalStateExceptions with user friendly error messages. (See CoreWalletsService.java for example.)
The new method returns current buy or sell offers for a fiat ccy. These changes need refactoring and polishing before merging, but they're committed in this state to be safe (don't lose work). Changes include: * New core.grpc classes CoreOffersService GrpcOffersService model.OfferInfo * CoreApi -- The new CoreOffersService is injected into CoreApi and the old getOffers() and placeOffer() impls were moved into the new CoreOffersService. The getOffers implementation was re-done. Other changes are just rearranging location of core method calls. * GrpcServer -- The new GrpcOffersService replaced the old GetOffersService and PlaceOfferService. * grpc.proto -- The old GetOffers and PlaceOffer services were combined into a single Offers service, and the PlaceOffer rpc was renamed as CreateOffer. These are the only substantive changes; the rest is just rearranging location of the service defs in the file. Also created a lighterweight OfferInfo proto message wrapper to be passed between server & client (client has no access to core's Offer and OfferPayload). * OfferInfo -- A new wrapper around the OfferInfo proto message. * CliMain -- The new GetOffers service stub was added. Some (maybe too much) number and ccy formatting logic was copied & modified from core. Some tedius string formatting was added too (needs to be tidied up). * License comments were also copied to several classes, and I made a mistake in reverting changes to the wrong file. TODO add unit tests
This change moves logic for formatting BTC balances, dates and tables out of CliMain. Two new output formatting classes were added: CurrencyFormat and TableFormat.
This commit is for a change requested in PR 4308: bisq-network#4308 (review) ".toUpperCase() seems misplaced here. It would soon get repetive. Whether the underlying logic differentiates between capitalizations is a low-level implementation detail and would do better at the lowest practical level."
Created a new TableFormat.formatPaymentAcctTbl method. Also: * Defined new "Currency" and "Name" column headers in TableFormat. * Changed syntax of stream().map() calls in some TableFormat methods. * Fixed verbose return statement in TableFormat.getLengthOfLongestColumn. This commit is out of scope for the getoffers PR (4329), but is included as part of the migration of all console tbl formatting from the client into TableFormat.
This change simplifies client 'createpaymentacct' method parameter validation. It no longer assumes parameter ordering is correct, and only verifies the string parameter count is correct. A unit test was also added to cli/test.sh This commit is in response to the requested change in PR 4308. bisq-network#4308 (review)
This change adds a new 'verifyWalletsAreAvailable' method to the client, which eliminates this duplicated statement: throw new IllegalStateException("wallet is not yet available"); The commit is in response to a requested change in PR 4312: bisq-network#4312 (review)
paymentAccount, | ||
useSavingsWallet, | ||
resultHandler); | ||
} |
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.
It took me a minute to realise that the difference between these methods is that one of them takes primitives and the other takes higher level abstractions. I'm leaving this comment as an annotation for myself.
This change simplifies client 'getoffers' method parameter validation. It no longer assumes parameter ordering is correct, nor validates the direction parameter value. The client only verifies the correct number of string parameters are present.
Respect the direction parmeter; do not give it meaning it does not have. If the user passes a 'buy' parameter, return buy offers. Do not misinterpret the param's intent. The direction parameter's value does not imply "buy=I'm a buyer, show me sell offers" or "sell=I'm a seller, show me buy offers". I got mixed up by looking at the UI. If I want to sell BTC, I click the SELL tab to view buy offers (maker as buyer). If I want to buy BTC, I click the BUY tab to view sell offers (maker as seller). This change also fixes an offer list sorting bug. The commit is in response to a requested changes in PR 4329: bisq-network#4329 (review)
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.
Oh, I forgot that the locale/timezone changes are pending.
We display all dates in UTC, using the "yyyy-MM-dd'T'HH:mm:ss'Z'" format.
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
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.
ACK
Respect the direction parmeter; do not give it meaning it does not have. If the user passes a 'buy' parameter, return buy offers. Do not misinterpret the param's intent. The direction parameter's value does not imply "buy=I'm a buyer, show me sell offers" or "sell=I'm a seller, show me buy offers". I got mixed up by looking at the UI. If I want to sell BTC, I click the SELL tab to view buy offers (maker as buyer). If I want to buy BTC, I click the BUY tab to view sell offers (maker as seller). This change also fixes an offer list sorting bug. The commit is in response to a requested changes in PR 4329: bisq-network#4329 (review)
The new method returns current buy or sell offers for a fiat ccy.
This PR should be reviewed/merged after PR 4324.
Changes include:
New core.grpc classes
CoreOffersService
GrpcOffersService
model.OfferInfo
CoreApi -- The new CoreOffersService is injected into CoreApi and
the old getOffers() and placeOffer() impls were moved into the
new CoreOffersService. The getOffers implementation was re-done.
Other changes are just rearranging location of core method calls.
GrpcServer -- The new GrpcOffersService replaced the old
GetOffersService and PlaceOfferService.
grpc.proto -- The old GetOffers and PlaceOffer services were combined
into a single Offers service, and the PlaceOffer rpc was renamed
as CreateOffer. These are the only substantive changes; the rest
is just rearranging location of the service defs in the file.
Also created a lighterweight OfferInfo proto message wrapper to
be passed between server & client (client has no access to core's
Offer and OfferPayload).
OfferInfo -- A new wrapper around the OfferInfo proto message.
CliMain -- The new GetOffers service stub was added.
Some (maybe too much) number and ccy formatting logic was
copied & modified from core. Some tedius string formatting
was added too (needs to be tidied up).
License comments were also copied to several classes, and I
made a mistake in reverting changes to the wrong file.
Added unit tests to cli/test.sh.