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
- Updated expected model roles (removed `selfDestruct` and `selfDestructAmount`)
- Self destruct tokens list management is now done inside `SelfDestructPopup).
- Store receives a js array with {walletAddress, amount} roles.
- 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?
Fixes#10523
The problem was that the CreateChatView now uses an isolated Chat RootStore, since we can't be sure if the personal chat section will be loaded yet.
To fix that, I created a new store that is only for storing the properties needed for that new chat. That way we are sure that it is created and shared to necessary components.
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
The warning for not supported bigger than 99 for the account index
make sense only for standard derivation paths that we support.
Also added test case to story book for investigating the issue #10479
updates #10479
Khushboo Mehta
Cuteivist
Patryk Osmaczko
Stefan
Michał Cieślak
Alexandra Betouni
Anthony Laibe
Jonathan Rainville
Michal Iskierko
Noelia
mprakhov
Alex Jbanca
Igor Sirotin
Anastasiya S
Boris Melnik
Vladimir Druzhinin
Jakub Sokołowski
Pascal Precht
Sale Djenic