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
Also:
test(suite_communities): Fixed community related tests
- A new intermediate popup is now displayed when user clicks on `Create New Community` button from `Community Portal`.
- Reformulated `tst_communityPermissions` since now it is a default option without the need of activating it from experimental feature's section.
Closes#10115
disable retranslation, display a confirmation dialog and apply the
language change after app restart
rationale: the way the retranslation works internally is that it force
reevaluation of _all_ QML bindings which:
- might lead to crashes (immediately or later)
- lots of warnings printed to console, some bindings can get broken as a result
- not all UI is correctly retranslated on the fly (we have lots of places
where we assign the text imperatively via JS code), so these wouldn't
appear translated before app restart anyway
Fixes#7823
In case an account being deleted is migrated to a Keycard keystore file it was not removed from
`keycards_accounts` table and in case it was the last account for that keypair derived from keystore
file was not removed as well as other keycards containing the same keypair. That's all sorted out.
Fixes#10428
The issue above happened when you double click on a chat section. It causes the fetch to happen twice, which is wasteful, but also causes the model to get reset while it's being processed, thus creating the crash.
The fix here is to not signal that we are changing section if we are trying to switch to the section which is already active (makes sense ofc)
