Also
- fix the other saved addresses that were relying on the order of
buttons and fail after adding the favourite button
- improve the rest of the tests
- improve debug buttons
- extend driver with helper functions
Closes: #6898
Depends on statug-go favourite flag extension and merging of `favourites`
with `saved_address` tables and API
Additional changes:
- Remove duplicate name instead of ESN
Closes: #6546
An explanation why we keep track of `timestamp` and `localTimestamp` here,
introduction of those two actually fixes the following issues:
- https://github.com/status-im/status-desktop/issues/6004
- https://github.com/status-im/status-desktop/issues/7058
We should always refer to `whisperTimestamp` as it is set for a message by the network
in order they are sent (that solves the issue #6004), but another issue #7058 is happening
cause `whisperTimestamp` has one second accuracy (which is a very big timeframe for messages).
That further means that all messsages sent by user A within 1000ms will be received with the
same `whisperTimestamp` value on the side of user B, in that case to differ the order of
those message we're using localy set `timestamp` on the sender side which is received unchanged
on the receiver side.
Now a question why don't we use only locally set `timestamp` may araise... the answer is...
because of issue #6004, cause it can be that users A and B send a message in almost the same
time in that case message sent by user A will be immediatelly added to the message list, while
message sent by user B will arrive like a less then a second later and in that case user A may
see user B message before or after his message and the same for user B, depends on local time
of those 2 users which is set for `timestamp` time in the moment they sent a message.
If we anyhow find a way to have here accutacy higher than 1 second, then we can go on only
with `whisperTimestamp`
3f987cc565/protocol/messenger.go (L3726)Fixes: #7058
- `Setup a new Keycard with an existing account` flow improved
- code review comments applied
- Qml part updated due to the latest `StatusListItem` changes in `StatusQ`
Changes done within this commit were required by the latest keycard
library change, where we gave up of sending few signals when we're
running/resuming flow, which were sent before (those were signal notifying
about unplugged reader, card not inserted and card inserted, they are sent
by the keycard lib now only if that is really needed).
- Added flow which covers `Setup a new Keycard with an existing account` from
the keycard settings part (though two sub-flows there are missing, `Unlock Keycard`
and `Authentication` cause we don't have them yet).
- Updated factory reset flow (part of shared module) that it can read and display metadata
from a keycard if they are set, with this update this flow is almost complete, we are missing
`Unlock Keycard` flow for it as well.
New procs added:
- accounts service `createAccountFromMnemonic`
- accounts service `convertToKeycardAccount`
- accounts service `verifyPassword`
- wallet service `fetchBalanceForAddress`
Keycard library from this commit brings new changes in terms of
signals being sent by the lib in case of reader is not plugged in,
card is not inserted, card is inserted, that means the following
signals are sent only when it's really needed:
`"{\"type\":\"keycard.flow-result\",\"event\":{\"error\":\"connection-error\"}}"`
`"{\"type\":\"keycard.action.insert-card\",\"event\":{\"error\":\"connection-error\"}}"`
`"{\"type\":\"keycard.action.card-inserted\",\"event\":{}}"`
- pull in required StatusQ changes (see status-im/StatusQ#882)
- simplify the radio buttons handling, no need for a ButtonGroup as they
share the same parent
- the radio buttons have the desired font size as a result ;)
Patryk Osmaczko
Jonathan Rainville
Anthony Laibe
Lukáš Tinkl
PavelS
Stefan
MishkaRogachev
Michal Iskierko
Khushboo Mehta
Igor Sirotin
Michał Cieślak
Richard Ramos
Alexandra Betouni
Sale Djenic