This change supports creation of BSQ BLOCKCHAIN payment method accounts.
- Added proto message defs to grpc.proto.
- Added grpc server boilerplate to GrpcPaymentAccountsService.
- Added server impl to CoreApi, CorePaymentAccountsService.
- Added createcryptopaymentacct-help.txt.
- Added CLI side support for new api method.
- Added opt parsing unit tests to OptionParsersTest.
This is the 1st PR in a series, with the goal of supporting the BTC/BSQ trading
pair. Support for other crypto currency payment accounts will be added later.
This change sets the WalletsManager key the first time `unlockwallet` is called.
This is necessary because the key cannot be set during api daemon startup, as it
normally is at UI startup. See commit eb15fda229.
Running the UI's walletPasswordHandler during wallet initialization will fail
and block wallet initialization. This change ensures an encrypted wallet
does not trigger a walletPasswordHandler.run() if isApiUser=true during startup.
Make it clear the user needs to enter a two letter country code
in json form's "country" field, not a country name.
The json form's field name was not changed to "countryCode" in
this change for the following reason:
The API's payment account forms are dynamically generated using
reflection, and PaymentAccount class hierarchy @Setter methods
determine which form fields are included or excluded. Reflection
and @Setter methods are also used when reading completed json
forms, to set the field values on a new PaymentAccount instance
before it is persisted.
CountryBasedPaymentAccount subclasses have a country field and a
@Setter, not a countryCode field, hence this shortcut to informing
the user the country field value is a country-code.
renamed alertCountProperty to badgeCountProperty
changed the badge counting policy so that the count of chat messages does not contribute to the badge number, but merely the presence of chat messages, and/or the new flag.
show an explanatory message when trader is not allowed to close own dispute ticket
removed some comments and code that were accidentally included from PR5160
renamed variable tpe to tradePeriodEnd
renamed variable cptyName to counterpartyName
clear the new badge on double-click of dispute tablerow
This change uses recently added walletService.isAddressUnused to ensure
the api's CoreWalletsService creates an unused address if none exists.
- grpc.proto: Add bool isAddressUnused field to message AddressBalanceInfo.
- AddressBalanceInfo: Adjust AddressBalanceInfo proto wrapper.
- CoreWalletsService: Use walletService.isAddressUnused in getFundingAddresses.
- GrpcClient: Adjust to modified AddressBalanceInfo.
- TableFormat, ColumnHeaderConstants: Add 'Is Used' column to getfundingaddresses output.
Note: bugfix is out of scope for this PR, but the test case helped expose this bug.
- Add description msg TakeOfferReply proto, and fromProto method
to core.offer.enum AvailabilityResult. The description field
maps a client usable error message to the enum.
- Adjust GrpcErrorMessageHandler to add AvailabilityResult.description()
to takeoffer reply.
- Refactor (split up) GrpcClient's takeOffer. Add getTakeOfferReply()
to give clients a chance to make choices based on the reply's
AvailabilityResult when the takeoffer command did not result in a
trade. (Some errors are fatal, some not.)
- GrpcErrorMessageHandler A new ErrorMessageHandler implementation
to get around the api specific problem of having to use Task
ErrorMessageHandlers that build task error messages for the UI.
- GrpcExceptionHandler A new method for working with the
ErrorMessageHandler interface.
- GrpcTradesService, CoreApi, CoreTradesService: Ajdusted takeoffer
error handling to give a failure reason provided by the new
GrpcErrorMessageHandler.
After GrpcServer builds a gRPC server instance, it calls injected
CoreContext#setApiUser(true). The same, singleton CoreContext object
is injected into CoreService constructors, which use the coreContext#
isApiUser value (set true by the server builder) to set their own class
level boolean isApiUser fields.
When CoreContext was added, I was fooled by the correct behavior I
saw while stepping through the server debugger. But now I see that
the correct boolean value in CoreContext is only available after
CoreService constructors have finished instantiating themselves -
- not in time.
In this change, the CoreContext becomes a class level final field
in CoreServices, and the correct coreContex.isApiUser value is available
in the CoreService methods.
