Commit Graph

14 Commits

Author SHA1 Message Date
Patryk Osmaczko 5162c285a8 refactor: introduce `newTestCommunitiesMessenger` 2024-01-24 14:24:57 +01:00
Roman Volosovskyi 0bd4a06edc Comment out all logged flaky tests 2024-01-18 06:36:12 +00:00
Mykhailo Prakhov a5f6a6c2f6
fix: privileged member accepted/rejected request to join action is not approved by the control node after the member leaved and tries to join the community again (#4487) 2023-12-19 14:45:34 +01:00
Patryk Osmaczko 4086e24365 fix: close messenger's databases in tests 2023-11-28 20:59:25 +01:00
Patryk Osmaczko 0881d8cdb0 Add queue for processing community description & configurable control node 2023-10-17 21:00:24 +01:00
Patryk Osmaczko bb7273cf6f feat: allow for pending community request state changes
iterates: status-im/status-desktop#11842
2023-10-05 09:24:45 +02:00
Mykhailo Prakhov db9adb631f
feat: share requests to join and revealed addresses with privileged roles (#3951)
- share requests to join with new privileged roles during reevaluating member role
- share requests to join with new members, joined the community as TOKEN_MASTER, ADMIN
- share requests to join revealed addresses to ADMINS and TOKEN_MASTERS
- refactor common test functionality to make them more predictable
- removed unused CommunityToken protobuf
2023-09-20 10:37:46 +02:00
Mykhailo Prakhov 86d969727f
feat: share CommunityTokens between privileged users (#3931)
feat: sync CommunityTokens between privileged users
feat: restore PrivilegeLevel for synchronized CommunityToken
2023-08-22 19:48:42 +02:00
Mykhailo Prakhov e7f5f32298
feat: synchronize community token between TokenMasters and Owners (#3893) 2023-08-15 19:42:40 +02:00
Mykhailo Prakhov 7eac9b170c
feat: community privileged user sync message (#3879) 2023-08-15 17:27:01 +02:00
Mykhailo Prakhov ebadfb3e7b
feat: allow owner without community private key to manage privileged community permissions (#3861)
feat: allow owner without community private key to manage privileged permissions
2023-08-08 17:02:56 +02:00
Pascal Precht 248e4a7f24 refactor: EventSenders forward RequestToJoin decision to control node
This is a bigger change in how community membership requests are handled
among admins, token masters, owners, and control nodes.

Prior to this commit, all privileged users, also known as
`EventSenders`, were able to accept and reject community membership
requests and those changes would be applied by all users.

This commit changes this behaviour such that:

1. EventSenders can make a decision (accept, reject), but merely forward
   their decision to the control node, which ultimately has to confirm
   it
2. EventSenders are no longer removing or adding members to and from
   communities
3. When an eventsender signaled a decision, the membership request will
   enter a pending state (acceptedPending or rejectedPending)
4. Once a decision was made by one eventsender, no other eventsender can
   override that decision

This implementation is covered with a bunch of tests:

- Ensure that decision made by event sender is shared with other event
  senders
  - `testAcceptMemberRequestToJoinResponseSharedWithOtherEventSenders()`
  - `testRejectMemberRequestToJoinResponseSharedWithOtherEventSenders()`
- Ensure memebrship request stays pending, until control node has
  confirmed decision by event senders
  - `testAcceptMemberRequestToJoinNotConfirmedByControlNode()`
  - `testRejectMemberRequestToJoinNotConfirmedByControlNode()`
- Ensure that decision made by event sender cannot be overriden by other
  event senders
  - `testEventSenderCannotOverrideRequestToJoinState()`

These test cases live in three test suites for different event sender
types respectively

- `OwnerWithoutCommunityKeyCommunityEventsSuite`
- `TokenMasterCommunityEventsSuite`
- `AdminCommunityEventsSuite`

In addition to the changes mentioned above, there's also a smaller
changes that ensures membership requests to *not* attached revealed wallet
addresses when the requests are sent to event senders (in addition to
control nodes).

Requests send to a control node will still include revealed addresses as
the control node needs them to verify token permissions.

This commit does not yet handle the case of event senders attempting to
kick and ban members.

Similar to accepting and rejecting membership requests, kicking and
banning need a new pending state. However, we don't track such state in
local databases yet so those two cases will be handled in future commit
to not have this commit grow larger.
2023-08-08 14:46:03 +02:00
Mykhailo Prakhov 3bd972dec4
chore: Added TokenMaster permission token type (#3848) 2023-08-04 12:28:46 +02:00
Mykhailo Prakhov f89eee9f40
feat: register new community member role ROLE_TOKEN_MASTER and grant him admin permissions (#3810)
feat: register new member type TokenMaster and grant him admin permissions
2023-07-26 18:01:19 +02:00