This commit contains most of the changes suggested by @chimp1984 in
his api-suggestions branch. See
961703ecea
A new 'registerdisputeagent' method was also added to MainCli, finishing
the work to support registration of mediators and refund agents on
arbitration daemons running in regtest mode. This method cannot be
used to register dispute agents on mainnet; users will see an error
msg if they try.
The :apitest GrpcStubs class was removed and recreated in the :cli
subproject, to be used by both :cli and :apitest. CliMain was changed
to use the new GrpcStubs.
* The bats test script was moved to the apitest subproject and renamed.
* Version tests were updated for release 1.3.7.
* The duplicated "test getoffers buy eur check return status" was
replaced by a new "test getoffers sell eur check return status" test.
* The bats dependency was switched to bats-core because development
has halted on https://github.com/sstephenson/bats/tree/master.
The new bats repository is
https://github.com/bats-core/bats-core/tree/master
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:
https://github.com/bisq-network/bisq/pull/4329#pullrequestreview-436033502
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.
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.
https://github.com/bisq-network/bisq/pull/4308#pullrequestreview-435052357
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 commit is for a change requested in PR 4308:
https://github.com/bisq-network/bisq/pull/4308#pullrequestreview-435055483
".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."
This change moves logic for formatting BTC balances, dates and
tables out of CliMain. Two new output formatting classes were
added: CurrencyFormat and TableFormat.
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
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 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 https://github.com/bisq-network/bisq/pull/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 https://github.com/bisq-network/bisq/pull/4308
This PR's branch was created from the PR 4308 branch.
This addresses task 4 in issue 4257.
https://github.com/bisq-network/bisq/issues/4257
This PR should be reviewed/merged after PR 4304.
https://github.com/bisq-network/bisq/pull/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 addresses task 2 in issue 4257
https://github.com/bisq-network/bisq/issues/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 #1 in issue https://github.com/bisq-network/bisq/issues/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 #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.
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 commit factors out a run() method in CliMain that either returns
(void) or throws an exception. This eliminates the need to call
System.exit in so many places as were previously. Indeed, now there is
only one place where System.exit is called.
It also removes the duplication of printing "Error: ..." to stderr when
something goes wrong by doing this once in the global catch clause in
the main method.
Previously, each wallet-related method was implemented with its own grpc
service. There is no need to do this, as a grpc service may declare
multiple rpc methods. This commit refactors everything wallet-related
into a single GrpcWalletService and also extracts a CoreWalletService
from CoreApi in order to avoid the latter becoming overly large.
Ideally, there would be no need for an abstraction in bisq.grpc called
CoreWalletService; we would ideally use such a service implemented in
bisq.core. The closest we have is WalletsManager, but it is not designed
to be used the way we are using it here in the grpc context. Rather than
making changes directly to core (which can be very risky), we will
rather make them here in this layer, designing exactly the "core wallet
service" we need, and can then later see about folding it into the
actual core.
This change removes non-idiomatic gRPC *Reply proto message fields.
The client should not receive success/fail values from server methods
with a void return type, nor an optional error_message from any server
method. This change improves error handling by wrapping an appropriate
gRPC Status with a meaningful error description in a StatusRuntimeException,
and placing it in the server's response StreamObserver. User error
messages are mapped to general purpose gRPC Status codes in a new ApiStatus
enum class. (Maybe ApiStatus should be renamed to CoreApiStatus.)
Implemented lockwallet, unlockwallet, removewalletpassword, and
setwalletpassword methods with basic error handling.
Also added basic error handling to existing getbalance method,
and removed unused BalancePresentation from CoreAPI.
TODO: update help text
This is a partial reversion of the earlier commit. Marking the password
option as required at the parser level made it impossible to run
./bisq-cli without options or arguments and get the help text. This is a
useful thing to do, and not worth creating a bad user experience to get
the free required option error handling and error messaging.
Stop attempting to align Option and Method description columns with one
another. It's a moving target as we add options and method names, and
this help output format will probably change in the future anyway.
Don't instruct the user to create a fresh data directory every time, as
this takes quite a bit longer to initialize the wallet than running
against the same data directory repeatedly. Just be clear that the
requirement is an unencrypted wallet with 0 BTC balance.
