[EPIC] Flows clarifying what happens when admins add/edit/delete permissions, kick and ban members and accept/reject join requests while control node offline

benjthayer commented 1 year ago

When the control node is offline, the following admin performed actions are placed into a pending state until the owner node is back online.

Adding, duplicating, editing and deleting permissions
Accepting / rejecting join requests
Kicking and banning members

Adding, duplicating, editing and deleting permissions

Designs: https://www.figma.com/file/17fc13UBFvInrLgNUKJJg5/Kuba%E2%8E%9CDesktop?type=design&node-id=35910-617973&mode=design&t=vB0RiqDZSw5MXe5x-4

Key features:

When adding, edting or duplicating a permission, a new warning panel (in orange) is displayed informing the user any permission changes will come into effect once the control node is back online.
Admins can add, duplicate, edit and delete permissions while control node offline.
When doing so, the permission title is moved into a pending state depending on the action taken
As soon as the control node is back online, the action is completed

Accepting / rejecting join requests

Designs: https://www.figma.com/file/17fc13UBFvInrLgNUKJJg5/Kuba%E2%8E%9CDesktop?type=design&node-id=35909-605774&mode=design&t=vB0RiqDZSw5MXe5x-4

Key features:

When accepting/rejecting, the accept/reject button moves into a disabled pending state.
The actioning admin can change their decision as required until the control node comes back online.
Other admins (those that did not perform the initial accept/reject) do not have the ability to override the decision made by the admin that initially actioned on the join request
Other admins see the disabled pending state of the accept/reject pending button
Users are only moved into the relevant tab in the Members section (All members if join request accepted, Rejected if rejected) once the control node comes back online

Kicking and banning members

Designs: https://www.figma.com/file/17fc13UBFvInrLgNUKJJg5/Kuba%E2%8E%9CDesktop?type=design&node-id=35909-607522&mode=design&t=vB0RiqDZSw5MXe5x-4

Key features:

When kicking/banning, the Kick/Ban button moves into a disabled pending state.
For simplicity, the actioning admin cannot change their decision (i.e. they cannot unban if they selected ban or access the kick button either).
Other admins (those that did not perform the initial kick/ban) do not have the ability to override the decision made by the admin that initially performed the action
Other admins see the disabled pending state of the kick/ban pending button
Members are only moved into the Banned tab once the control node comes back online.

Relates to: https://github.com/status-im/status-desktop/issues/11573#issuecomment-1644068733

cc @John-44 @jrainville @0x-r4bbit @mprakhov @osmaczko (apologies if I missed anyone!)

Please update the epic status to QA when it is ready for testing

QA Tasks

[ ] QA epic https://github.com/status-im/desktop-qa-automation/issues/134

benjthayer commented 1 year ago

We may wish to discuss, in the instance of the admin performing the kick/ban function, whether while in the pending state, they should be able to undo the ban or change from kick to ban / ban to kick while the control node is offline.

One scenario I can think of is if an admin decides to kick a member but that member then performs an even greater infraction and the admin decides to escalate the kick to a ban all while the control node is offline. Having this ability to change their mind/escalate the decision would mean they wouldn't need to go back and action the ban once the control node is back online.

cc @John-44