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.