Bump status-go HEAD that removes deletion of pending multi-transactions
in status-go
Previous implementation was relying on the fact that all pending
transactions are also multi-transactions, which it seems not to be
the case (e.g. ens, airdrop collectible)
Also tried to extend the deletion of multi-transactions to status go
but it was causing crashes for minted/dropped tokens.
Updates #10474
- replace qml owners model with Nim one
- get token owners from wallet service
- keeping owners cache in community_tokens/service and refresh every 10 minutes
Issue #10254
Fixes#10340
Fixes a race condition when receiving a message in a channel that doesn't exist yet (for example in a delete 1-1 chat).
What happens is that the status-go signal contains both the message and the chat. Both are handled by different services, so there was a race between the two of them. If the chat service handled the chat first, then the message was added correctly, but in the case of the message service handling it first, it would try to add the message to a chat that doesn't exist yet, so it wouldn't work.
I also cleaned the ChatUpdateArgs by removing the messages arg that was not used anywhere and also was a bit counter-intuitive. Why did a Chat arg have messages?
was deleted
This is needed because there's cases where the deletion of a permission
might cause the current user to no longer be eligible to join
a community.
Community has the follwoing permissions:
- own 2 ETH and 1 FOO_NFT or
- own 1 FOO_NFT
User owns: 1 FOO_NFT
^ The above would make the user eligible to request access to join.
Now if the community removes the second permission, the user now no
longer fulfills the requirements so we need to ensure the UI
permits the user to request access.
Rebuilding the permissions model (including its token criteria) sets the
necessary flags in the UI automatically.
There are a bunch of notification related settings that cause RPC
calls when read from the UI in QML/Qt.
This is bad because whenever the view tries to read a notification
setting it causes an RPC call and then rerenders the view. This happens
pretty much every time a new signal arrives in the client.
To account for that we now fetch all notification settings once and mark
the service as initialized so it know when to simply return cached
values. The cache is updated when the notification settings change.
Fixes#10493
Fixes#10076
Reverts the refactor that makes getChannelGroups (ie getChats) not return chats (now it does return all chats too).
That way, we actually have the right mentions and unread count when receiving new messages
Also fixes an issue where mentions and unread count would get reset to 0 when getting a community update, because the signal doesn't have enough info
