[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]

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:
#11573 (comment)

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 [EPIC][Permissions][QA] Flows clarifying what happens when admins add/edit/delete permissions, kick and ban members and accept/reject join requests while control node offline desktop-qa-automation#134

[benjthayer]

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

[noeliaSD]

Splitted task in smaller ones:

• [Permissions] Adding, duplicating, editing and deleting permissions when control node is offline #11769
• [Community] Accepting / rejecting join requests when control node is offline #11770
• [Community] Kicking and banning members when control node is offline #11771

[alexjba]

Added the UI task needed to show Accept/Reject buttons only to the admin that initially Accepted/Rejected the request. It needs backend support.

• [Community] Show Accept/Reject buttons to the admin that initiated the pending state #11824

CC @0x-r4bbit

[alexandraB99]

blocked due to #11824

[alexjba]

Added new UI task based on Design updates:

• [Community] Update Accept/Reject pending design in membership page #11895

[noeliaSD]

Following priorities of milestone 0.15.5 and team workload, this one is moved to the next iteration.

[iurimatias]

moving to next milestone due to lack of space in this one