We remove the shared accounts to send normal admins to not leak the addresses, however, that was a destructive action that also removed them from the `requestToJoin` param, which is reused later in the code, so it created an unwanted side effect. The side effect is now erased.
* feat_: log error and stacktrace when panic in goroutine
* test_: add test TestSafeGo
* chore_: rename logAndCall to call
* chore_: rename SafeGo to Go
* chore_: make lint-fix
* chore_: use t.Cleanup
* chore_: Revert "chore_: use t.Cleanup"
This reverts commit 4eb420d179cc0e208e84c13cb941e6b3d1ed9819.
* chore_: Revert "chore_: make lint-fix"
This reverts commit fcc995f157e671a4229b47419c3a0e4004b5fdab.
* chore_: Revert "chore_: rename SafeGo to Go"
This reverts commit a6d73d6df583f313032d79aac62f66328039cb55.
* chore_: Revert "chore_: rename logAndCall to call"
This reverts commit 8fbe993bedb9fbba67349a44f151e2dd5e3bc4cc.
* chore_: Revert "test_: add test TestSafeGo"
This reverts commit a1fa91839f3960398980c6bf456e6462ec944819.
* chore_: Revert "feat_: log error and stacktrace when panic in goroutine"
This reverts commit f612dd828fa2ce410d0e806fe773ecbe3e86a68a.
* feat_: log error and stacktrace when panic in goroutine
* chore_: make lint-fix
* chore_: rename logAndCall to call
* chore_: renaming LogOnPanic
* chore_: update rest goroutine function calls
* chore_: make lint-fix
* feat_: accept community join request with mvds
* chore_: no sender when use mvds in comm join response
* fix_: only use mvds for tokenized communities
* chore_: add comment for this.
- TokenMaster request shared addresses on restoring from a backup
- Fixes sharing members revealed adresses
- Filter out outdated ApplicationMetadataMessage_COMMUNITY_PRIVILEGED_USER_SYNC_MESSAGE messages
Fixes https://github.com/status-im/status-desktop/issues/15175
The problem was that we used StartMembersReevaluaitonLoop in createCommunityPermission, in case the loop was never started. Indeed it worked if it was the first ever permission, because the loop would then start and members would be re-evaluated.
However, if the loop was already started, in the case where there were previous permissions, the call would just early exit, because it was already started.
The solution here is to use `ScheduleMembersReevaluaiton` like other permission functions use. To make sure a first permission still works, we call startLoop in schedule if the task doesn't exist.
That's an optimisation. Instead of fetching collectibles owners for each
member, it is fetched once, before members iteration.
It should significantly reduce amount of queries to providers.
closes: status-im/status-desktop#14914
I've renamed TorrentManager to ArchiveManager, ArchiveManager to ArchiveFileManager, TorrentContract to ArchiveService, ArchiveContract to ArchiveFileService. I've also renamed all init functions and struct fields to the appropriate archive-centric naming.
I've removed any mention or dependency of TorrentManager from Manager. There is still more work to do, but Messenger now communicates directly with a TorrentManager rather than asking the communities Manager to handle it. I've ensured that LogStdout() is only called from TorrentManager and removed entirely from Manager, this functionality seems to be some kind of debug tool specifically for torrent related functionality. Next I need to focus on functions within Messenger that call a TorrentManager and see how to isolate these from the main flows, following that I also need fix the tests that are broken. I will also need to refactor torrentClientReady() so that it is a function of TorrentManager, this may allow for pushing more functions into TorrentManager which will lead to better torrent encapsulation.
I'm not particularly proud of this work. I've just passed in all the deps as vars, there are way too many concerns handled by the TorrentManager that I don't know what is the best approach to removing them. I've even resorted to declaring an 'Publisher' interface to handle all the 'publish()' calls the TorrentManager makes. Next up I need to resolved the communities Manager API, because I've removed all of its end points. The TorrentManager needs to be a lot more simple than it is.
Code moved into new TorrentManager. This commit is BROKEN! The code is not ready to use so don't use it, lots more work to do. Biggest problem is that the torrent management in Manager is very tightly coupled to sending encrypting etc. All of that needs to be prised apart
Send information to owners and token masters about operations: burn, airdrop, remote destruct.
Add CommunityTokenActionSignal to signalize client side.
Fix#13371
fix(communities)_: Receiving mention notifications (@everyone) from spectated communities #14798
Fix condition to check if user has joined community isCommunityJoinedBeforeClock
Fixes#14798
This avoids locking of the community until the end of reevaluation.
There is no special handling for community changes while reevaluation is
ongoing. If members are added or removed, the function will behave
correctly. If permissions are changed, they will be accommodated in the
next reevaluation.
fixes: status-im/status-desktop#14775
Light functions are based on the fact that permissions are met if the user is on community/channel member list.
If the user is not on the list, permissions will not be met and the client is responsible to use regular permissions-check functions.
For all permissions-check functions, corresponding light versions are added: CheckAllChannelsPermissionsLight,
CheckChannelPermissionsLight, CheckPermissionToJoinLight.
Issue #14220
Use EventWatcher to catch wallet events.
Handling all community tokens wallet events in communitytokens service (database and messenger operations).
Adding new signal to nim: CommunityTokenTransactionSignal, which is emitted everytime when the event is received.
Issue #4351
Patryk Osmaczko
Jonathan Rainville
frank
kaichao
Mykhailo Prakhov
Vitaly Vlasov
Prem Chaitanya Prathi
Andrey Bocharnikov
Michal Iskierko
Ivan Belyakov
Godfrain Jacques
Mikhail Rogachev
Samuel Hawksby-Robinson
Igor Sirotin
osmaczko