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 ;)
Enable preview for gifs after enabling the gif functionality
Disable gif functionality if the preview was disabled
Addition fixes
- The gifs weren't checked if all images weren't enabled
- The subdomain wasn't checked for whitelisting if the main domain wasn't enabled
- Image clicking
- Dismiss asking for unfurling was not updating the state
Considerations
- Looked into having the "gif enabled" - "tenor unfurling" relation
embedded in the controller but it would require extensive refactoring
by implementing a data-model for unfurling whitelisted domains
Closes: #6829
the "Recent emojis" was always empty until the user has clicked
additional emoji
loading the recent emojis in `Global.onSettingsLoaded` is too late; it's
executed long before the popup is opened; instead do it at the end of
parsing the categories
Stefan
MishkaRogachev
PavelS
Anthony Laibe
Michal Iskierko
Patryk Osmaczko
Khushboo Mehta
Igor Sirotin
Lukáš Tinkl
Michał Cieślak
Richard Ramos
Alexandra Betouni
Sale Djenic