// ObjectProperty with AssetTxProofResult does not notify changeListeners. Probably because AssetTxProofResult is
// an enum and enum does not support EqualsAndHashCode. Alternatively we could add a addListener and removeListener
// method and a listener interface, but the IntegerProperty seems to be less boilerplate.
This allows the user to change required confirmation and it has impact
on open requests. Will be read at parsing the result.
Changed also the text field to not listen on text change but on focus
out so that the values are only updated once the user has left the
field and the value is valid. Otherwise small numbers like 1 might be
written during typing. The other values are only read at request start
and changes will have no impact on already started requests.
Also applies previous value in case the user added an invalid value at
focus out.
- Made display text shorter and added a tooltip.
- Allow very high numbers in devmode as max conf value
This is another larger refactoring, sorry ;-)
But the structure was just not correct before. We had handled multiple
trades with multiple results and that is error prone. Now each class
has much more clear responsibilities. Also the result enums are not
changes so that they are better separated between result based and
service bases states.
All different states are still hard to test. We should set up some mock
service to simulate confirmations counting up and error scenarios.
- Do not use immutability for AutoConfirmSettings as it makes setting
values cumbersome.
- Add btc validator for trade limit
- Make AutoConfirmSettings an optional and add find method by currency
code to be better prepared when used for other coins.
- Add static getDefaultForXmr to AutoConfirmSettings
- Move listener creation to init method
to add auto confirm for other currencies in the future. The generic part
is only used where we would have issues with backward compatibility like
in the protobuf objects. Most of the current classes are kept XMR
specific and could be generalized once we add other assets, but that
would be an internal refactoring without breaking any network or
storage data. I think it would be premature to go further here as we
don't know the details of other use cases. I added the methods used from
clients to AutoConfirmResult, not sure if the API is well defined by
that, but as said that could become subject of a future refactoring once
another auto confirm feature gets added. Goal of that refactoring was
to avoid that we need more fields for trade and the the UI would have to
deal with lots of switch cases based on currency.
Sorry that is a larger commit, would have been hard to break up...
If a user has an existing account with phone number or email as
account ID we show a popup at startup where we require that he sets the
user name. This popup has no close button so he is forced to enter a
value. If there are multiple account multiple popups will be shown.
To not break signed accounts we keep accountId as internal id used for signing.
Old accounts get a popup to add the new required field userName but accountId is
left unchanged. Newly created accounts fill accountId with the value of userName.
In the UI we only use userName.
Input validation does only check for length (5-100 chars). Not sure what
are the requirements at Revolut. Can be changes easily if anyone gets
the specs.
Add re-open dispute button to mediation views (not refund agent as
there it might be dangerous if he would close 2 times and pay out twice.
If a dispute was reopened and a message was sent afterwards the receiver
will auto-reopen the dispute as well and the UI shows the number
indicator.
Add search field to traders dispute views.
Fix DisputeMsgEvents which was handling only legacy arbitration cases
and now uses mediation and refund agent. Used to update state in case
the UI is not selected.
Add "send private notification" button for mediators and refund agents.
Add report button for mediators and refund agents
Generates report text of all disputes with more detailed information
which should be used for reporting.
Add "Dump text of all disputes" button for getting a text representation
of all disputes including the messages for mediators and refund agents.
This is not used for report but might be useful for search, etc.
Do not show legacy arbitration tabs (for traders as well for
arbitrators) if no cases available.
Add 5 new enum entries for Reason for dispute:
OPTION_TRADE
SELLER_NOT_RESPONDING
WRONG_SENDER_ACCOUNT,
TRADE_ALREADY_SETTLED,
PEER_WAS_LATE
Hide NO_REPLY, SCAM and PROTOCOL_VIOLATION in UI (still in code if we still
need it and re-activate them).
Add report button:
Generates report text of all disputes with more detailed information
which should be used for reporting.
Add "Dump text of all disputes" button for getting a text representation
of all disputes including the messages. This is not used for report but
might be useful for search, etc.
Do not show legacy arbitration tabs (for traders as well for
arbitrators) if no cases available.
Add 3 new enum entries for Reason for dispute:
OPTION_TRADE
SELLER_NOT_RESPONDING
WRONG_SENDER_ACCOUNT
Hide NO_REPLY and PROTOCOL_VIOLATION in UI (still in code if we still
need it and re-activate them)
Use now the complete object data for signature creation. We use the protobuf data for creating the signature with DER encoding. We restict ourself more regarding backward compatibility but I think it is not a big problem.
If a new field is added to Filter and deployed the maintainer needs to publishes a new filter object. By using the new version he cannot remove the old filter from the network as the protobuf data is different and sig verification on the P2P datastorage level will fail. This is intended to keep the old filter alive for some time to support not updated users. We do not remove invalid filters anymore from our local storage to enable seed nodes to support also old filter objects.
For not updated users the new filter will fail at sig verification because the protobuf data is different. So they ignore the new filter and still use the old filter. For updated users the old filter will fail and the new filter is accepted. As it has a newer date it would also replace the old filter anyway. If the maintainer wants to delete the old filter from the network he can use the old app version and remove the filter. It is recommended to keep a copy of the data directory before the update so that the removal of the older filter is possible.
Refacorings:
- Rename isPeersPaymentAccountDataAreBanned to arePeersPaymentAccountDataBanned
- Rename isSignerPubKeyBanned to isWitnessSignerPubKeyBanned
