Some i18n property values can be used by the API if long strings are
wrapped before written as commments to json payment account forms, or
written to the CLI console.
This change anticipates the addition of the more complex Swift payment
method (PR 5672). PR 5672's i18n property value for key "payment.swift.info"
will be wrapped and appended to the comments of the Swift payment account's
json form.
Ad-hoc API testers need to be able to run the test harness without
interference from the production api method call rate meters.
This change overrides and disables most call rate meters when the
test harness is run from the ApiTestMain driver (no jupiter tests).
We can cache an offer payload hash as soon as its `offerFeePaymentTxId`
is set. (The payload hash cannot be calculated until the object can
be transformed into a protobuf message, which requires a non-null
offerFeePaymentTxId.)
Another benefit is removal of the payload hash argument from the
`OfferBookListItem` constructor.
Changes include
- `OfferPayload` Added `transient byte[] hash` field + getter method
(where hash is calculated and cached).
- `OfferBookService` Removed `P2PDataStorage.ByteArray hashOfPayload`
parameter from `OfferBookChangedListener` listener methods
`onAdded` & `onRemoved`. (Hash is cached in `OfferPayload`.)
- `P2PDataStorage` Added null check to `ByteArray` class constructor.
- `OfferBook` Adjusted for change to `OfferBookChangedListener`.
Also removed redundant payload hash null checks.
- `TakeOfferDataModel` and `MarketAlerts` Adjusted for change to
`OfferBookChangedListener`.
- `OfferBookListItem` Removed overloaded constructor with
`@Nullable P2PDataStorage.ByteArray hashOfPayload` parameter.
(Field value is set from cached offer payload hash.)
- `OfferBookViewModelTest` and `OfferMaker` Adjusted test and test fixture:
do not attempt to create offer payloads without an `offerFeePaymentTxId`.
The new debug log statements included in this PR help trace add/remove
list item actions if problems are seen in the UI's OfferBook, after the
API 'editoffer' method is released.
They can and should be removed in a future PR if the released API feature
proves it did not introduce bugs into the UI.
Checking offer payload hashes in OfferBook's onAdded and onRemove methods
is sufficient to prevent incorrect removal of offer list items from the
UI OfferBook view (where api 'editoffer' causes onRemoved to be called
after onAdded on peers).
Hash of protectedStorageEntry (should be offerPayload) was sometimes
resulting in incorrect hash being sent to OfferBook listener methods
onAdded(offer, hashOfPayload, sequenceNumber), and
onRemoved(offer, hashOfPayload, sequenceNumber).
Hash of OfferPayload is correctly passed to listener with this change.
Sending the correct hash allows removal of a dubious code block that
removed a book view list item when hash compare failed, and no matching
offer existed in the OfferBookService.
See https://github.com/bisq-network/bisq/pull/5659#discussion_r689634240
A newly created offer has no OpenOffer+State (AVAILABLE || DEACTIVATED)
when displayed in the CLI's console. This change adds a 'bool isMyPendingOffer'
to the OfferInfo proto + wrapper, and the CLI's console offer output formatter
uses it to determine if it should display a new offer's Enabled column value
as PENDING, instead of an ambiguous NO value.
This change is a refactoring for handling the removal of a peer UI's offer
item when it is deactivated and edited in the same CLI `editoffer` command.
On the API side, an `editoffer --price=N --enable=false` command results
in the edited offer not being re-published. On a UI peer's side, the edited
offer is not added to the peer's storage, and the peer's onRemoved(offer)
listener event does not find a storage entry with matching payload-hash.
This fix assumes an offer that is not in the local store should be removed
from the UI's view list -- when the onRemoved method's hashOfPayload does
not match the UI's view list item's hashOfPayload.
