- user is able to see community without being a member
- invitation bubble always display "Go to Community"
- join community buttons are displayed in community view
main part of: #7072
There was an issue where imported messages from third-party services
would cause super laggy scroll behaviour in the chat view.
The reason for that is that on scroll, the app keeps calling
`getVerificationRequestFrom()` on the chatkey of the community.
Typically the results of these requests are cached so that it should
perform the call only once, but because there's no actual verification
request/contact for the community chat key (all third-party messages are
signed by the community), the call keeps on happening over and over.
This commit adds a flag to `getContactDetailsAsJson` and `isEnsVerified`
to control whether or not the call to `getVerificationRequestFrom`
should in fact be made (which should not be the case for imported
messages).
The result of this is a smoother scrolling experience.
Fixes#7767
This adds the UI plus all necessary models and signal handling to render
discord import progress in the desktop application.
It also introduces message handling for discord chat message types.
Requires status-im/status-go#2826 to function
Co-authored with @caybro
Actually this is not a signing transaction, but rather authenticating logged in
user when he wants to send a transaction. An authentication is done by entering
password(regular user) or pin(keycard user).
A real signing transaction feature will be (hopefully) added in a near future where
we're going to sign a transaction on a keycard which corresponds to a certain
account, a user wants to send a transaction from.
To sum up... this change just removes password from the send modal and introduces
`Authenticate` flow instead.
Fixes: #7510
InvitationBubbleView.qml:
- rework view to use layouts properly
- add missing community identicon
Backend:
- remove local community requests on community join
- propagate SIGNAL_COMMUNITY_MY_REQUEST_ADDED to UI
fixes: #7139
This was never implemented, eventhough a similar approach is used with
the global AppSearch. Expose the method `scrollToMessage(messageId)` so
that it can be called from QML directly.
Fixes#7375
A new rule introduced which should provide easier tracking/maintainig
later. The rule says:
- popup contains up to 3 action buttons and one back button (optional)
- if 3 buttons are displayed in the popup then the most left button, but
not back button, always triggers tertiary action, middle button always
triggers secondary action and the most right button always triggers primary
action
- if 2 buttons are displayed, then:
- if one of them is "Cancel" (left button) it should trigger tertiary action
and the other one (right button) should trigger primary action
- if non of them is "Cancel" then the left button triggers secondary action
and the right button triggers primary action
- if single button is displayed, then:
- if it's "Cancel" it triggers tertiary action
- if it is not "Cancel" it triggers primary action
- tertiary action always reffers to the cancel action until otherwise set
- tertiary action will be always triggered by closing popup via keybord
(esc key) or clicking on top right `x` button on the popup
- Added `Authenticate` flow
- `Setup a new Keycard with an existing account` updated so it includes `Authenticate` flow
from the point where is needed (when migrating a profile keypair)
- We are missing `Unlock Keycard` flow for this one, will be added once it is developed
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.
