status-im
[Community] Show Accept/Reject buttons to the admin that initiated the pending state
Description
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: Once the membership request is in Accept Pending/Request Pending state, only the admin that made the initial decision can change the decision. (Other admins will not see the alternate button on hover).
Depends on #11842
I don't think that's the issue. #11842 is more about letting other admins who did that action, so that the originator and undo it. The status-go work to make the rejects pending is already done. I don't think we have an issue for the Nim and hook to QML part though
@jrainville This task is about hiding the Accept/Reject buttons if the current user is not the one that initiated the pending state. To do this we need to know what account initiated the pending state.
Ah yes, I missed the line at the bottom of the image. You're right then.
@alexjba we'll probably not have time to do the backend in time for 0.14.
I think we should split this one in two and have another smaller task to be done in the UI for now, which is to just hide the buttons when in the pending state (still show the disabled "Accept pending" though). That would be the base layer for the rest anyway.
What do you think? cc @alexandraB99
@alexjba we'll probably not have time to do the backend in time for 0.14.
I think we should split this one in two and have another smaller task to be done in the UI for now, which is to just hide the buttons when in the pending state (still show the disabled "Accept pending" though). That would be the base layer for the rest anyway.
What do you think? cc @alexandraB99
Sounds good to me! There is another task to update the Accept pending UI based on a new design. I could use that one to hide the Accept/Reject buttons in the pending state until we have the backend for it.
I've added this task to change the default visibility to false when the state is Accept/Reject pending. When the backend will be available, we can set the proper visibility value.
Following priorities of milestone 0.15.5 and team workload, this one is moved to the next iteration.
I've added this task to change the default visibility to false when the state is Accept/Reject pending. When the backend will be available, we can set the proper visibility value.
I guess this task can be unblocked. Could you confirm @jrainville ?
I've added this task to change the default visibility to false when the state is Accept/Reject pending. When the backend will be available, we can set the proper visibility value.
I guess this task can be unblocked. Could you confirm @jrainville ?
I know @osmaczko did some work on this, but I don't remember the exact state. Can you confirm @osmaczko ?
I've added this task to change the default visibility to false when the state is Accept/Reject pending. When the backend will be available, we can set the proper visibility value.
I guess this task can be unblocked. Could you confirm @jrainville ?
I know @osmaczko did some work on this, but I don't remember the exact state. Can you confirm @osmaczko ?
There is one last subtask to complete: https://github.com/status-im/status-desktop/issues/11842, which will enable admins to change their minds. It was blocked previously by the issues with eventual consistency of events but that was resolved.
Since https://github.com/status-im/status-desktop/issues/11902 was done, the state of accepting/rejecting requests by admins is okeyish. IMHO enabling admins to change their minds is nice but definitely not a must have at that stage.
