**This is a breaking change!**
Prior to this commit we had `AddCommunityToken(token *communities,
croppedImage CroppedImage)` that we used to
1. add a `CommunityToken` to the user's database and
2. to create a `CommunityTokenMetadata` from it which is then added to
the community's `CommunityDescription` and published to its members
However, I've then discovered that we need to separate these two things,
such that we can deploy a community token, then add it to the database
only for tracking purposes, **then** add it to the community description
(and propagate to members) once we know that the deploy tx indeed went
through.
To implement this, this commit introduces a new API
`SaveCommunityToken(token *communities.CommunityToken, croppedImage
CroppedImage)` which adds the token to the database only and doesn't
touch the community description.
The `AddCommunityToken` API is then changed that it's exclusively used
for adding an already saved `CommunityToken` to the community
description so it can be published to members. Hence, the signature is
now `AddCommunityToken(communityID string, chainID int, address
string)`, which makes this a breaking change.
Clients that used `AddCommunityToken()` before now need to ensure that
they first call `SaveCommunityToken()` as `AddCommunityToken()` will
fail otherwise.
* chore: make the owner without the community private key behave like an admin
* Add test for the owner without community key
* chore: refactor Community fn names related to the roles
If user followed onboarding flow to recover his account using seed phrase or keycard,
then `ProcessBackedupMessages` property of node config json object should be set to
`true`, otherwise it should be set to `false` or be omitted.
- Fixed redundant permissions check. If community is set to auto-accept,
then permissions would be checked twice, in
`HandleCommunityRequestToJoin` and `AcceptRequestToJoinCommunity`.
Mitigated it by returning from `HandleCommunityRequestToJoin` immediately
in case of auto-accept.
- Extracted `accountsSatisfyPermissionsToJoin` to remove code
duplication and simplify the logic.
* feat: add api to remove private key and separete owner from private key ownership
For https://github.com/status-im/status-desktop/issues/11475
* feat: introduce IsControlNode for Community
* feat: remove community private key from syncing
* feat: add IsControlNode flag to Community json serialisation
* Update protocol/protobuf/pairing.proto
Co-authored-by: Jonathan Rainville <rainville.jonathan@gmail.com>
---------
Co-authored-by: Jonathan Rainville <rainville.jonathan@gmail.com>
* mute and unmute all community chats when community mute status changes
* unmute community when atleast one channel is unmuted
* fix: save community, extend the function to save muted state and mute duration
chore:
- add CommunityEventsMessage
- refactor community_admin_event to accept a list of events and patch a CommunityDescription
- save/read community events into/from database
- publish and handle community events message
- fixed admin category tests
- rename AdminEvent to Events or CommunityEvents
Adds airdropAddress to the request to join params and a is_airdrop_address flag in the communities_requests_to_join_revealed_addresses table.
This airdropAddress is used by the owner to know which address to use when airdropping
I have encountered a crash in the app after syncing, looks like a
community has been created without a Config.
This crashes the app after the user logs in.
This commit prevents the app from crashing, but does not fix the
underlaying issue (that's something I will have to investigate).
Added tests to validate the behavior.
Check community exists
Mykhailo Prakhov
Pascal Precht
Boris Melnik
Stefan
Anthony Laibe
Sale Djenic
frank
Mikhail Rogachev
Samuel Hawksby-Robinson
Jonathan Rainville
Patryk Osmaczko
Cuteivist
John Ngei
Dario Gabriel Lipicar
Michal Iskierko
Andrea Maria Piana