No option to leave workspace as non owner admin
If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!
Version Number: 1.4.81-8 Reproducible in staging?: y Reproducible in production?: y If this was caught during regression testing, add the test name, ID and link from TestRail: Email or phone of affected tester (no customers): Logs: https://stackoverflow.com/c/expensify/questions/4856 Expensify/Expensify Issue URL: Issue reported by: @Beamanator Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1718092341741619
Action Performed:
- Create policy in NewDot
- Invite another user as admin
- Log in as that admin
- Open workspace members page & try to leave the workspace Expected Result:
Expected Result:
There's no way for you to leave a workspace, as an admin & not the owner
Actual Result:
There should be a way for a non-owner workspace admin to leave a workspace.
Workaround:
unknown
Platforms:
Which of our officially supported platforms is this issue occurring on?
- [x] Android: Native
- [x] Android: mWeb Chrome
- [x] iOS: Native
- [x] iOS: mWeb Safari
- [x] MacOS: Chrome / Safari
- [x] MacOS: Desktop
Screenshots/Videos
https://github.com/Expensify/App/assets/38435837/6a16587a-77da-48ab-a20a-505461c63013
Triggered auto assignment to @johncschuster (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.
Proposal
Please re-state the problem that we are trying to solve in this issue.
- There should be a way for a non-owner workspace admin to leave a workspace.
What is the root cause of that problem?
-
If the current user is admin, we always display button: https://github.com/Expensify/App/blob/8ed1e042af77ac0674941db9c80b67979426f7e8/src/pages/workspace/members/WorkspaceMemberDetailsPage.tsx#L186-L194
-
And the above button is disabled because of the condition: https://github.com/Expensify/App/blob/8ed1e042af77ac0674941db9c80b67979426f7e8/src/pages/workspace/members/WorkspaceMemberDetailsPage.tsx#L190
What changes do you think we should make in order to solve the problem?
- We can display the Button having the title "Leave" and when pressing on it, call
Policy.leaveWorkspace(policyID ?? ''). This button is only displayed if current user is admin and not a owner. To do that, we can update logic: - https://github.com/Expensify/App/blob/8ed1e042af77ac0674941db9c80b67979426f7e8/src/pages/workspace/members/WorkspaceMemberDetailsPage.tsx#L185-L195 to:
) : isCurrentUserAdmin && !isCurrentUserOwner ? (
<Button
text={'Leave'}
onPress={() => Policy.leaveWorkspace(policyID)}
medium
icon={Expensicons.RemoveMembers}
iconStyles={StyleUtils.getTransformScaleStyle(0.8)}
style={styles.mv5}
/>
) : (
<Button
text={translate('workspace.people.removeMemberButtonTitle')}
onPress={askForConfirmationToRemove}
medium
isDisabled={isSelectedMemberOwner || isSelectedMemberCurrentUser}
icon={Expensicons.RemoveMembers}
iconStyles={StyleUtils.getTransformScaleStyle(0.8)}
style={styles.mv5}
/>
)}
- We should add "Leave" option to this logic: https://github.com/Expensify/App/blob/8d11d0b185083a6a813daeb0fe7c0697a5627ef6/src/pages/workspace/WorkspacesListPage.tsx#L152 if current user is admin but not owner as well.
- Then BE need to fix the
LeavePolicyAPI so that non owner admin can leave workspace.
What alternative solutions did you explore? (Optional)
- With the member of the workspace who is not admin or owner, we also need to display "Leave" option which allows them to leave workspace as well because we already displayed "Leave" option in WorkspaceListPage if user is not admin and owner: https://github.com/Expensify/App/blob/8d11d0b185083a6a813daeb0fe7c0697a5627ef6/src/pages/workspace/WorkspacesListPage.tsx#L173-L179
Proposal
Please re-state the problem that we are trying to solve in this issue.
Admin is not able to remove himself from a workspace.
What is the root cause of that problem?
On the WorkspaceMemberDetailsPage, the "Remove from workspace" button is disabled when the selected member is the same user.
https://github.com/Expensify/App/blob/3523ca61b3c6060990983c27a80b85e140541498/src/pages/workspace/members/WorkspaceMemberDetailsPage.tsx#L190
What changes do you think we should make in order to solve the problem?
As requested in this issue, we should not disable the "Remove from workspace" button for the user.
We can remove the isSelectedMemberCurrentUser check.
https://github.com/Expensify/App/blob/3523ca61b3c6060990983c27a80b85e140541498/src/pages/workspace/members/WorkspaceMemberDetailsPage.tsx#L190
We can modify the isSelectedMemberCurrentUser check to ensure the user is an admin. If the selected member is the same user and he is an admin isCurrentUserAdmin, we should not disable the "Remove from workspace" button.
What alternative solutions did you explore?
FYI we haven't added the Help Wanted label yet b/c we're still designing out exactly how we want this to work, so I wouldn't recommend adding proposals yet 😅
Thanks for the update, @Beamanator. In that case, should this be Daily?
@Beamanator, did the discussion land on this?
Fair, maybe weekly is better 😅 I have been OOO yesterday and most of last friday so i have some stuff to catch up on, but the latest should be in the linked slack thread! I can try to look at this today soonish as well :D
Discussion is still ongoing in Slack (looks like we're close to a path forward).
Setting this to Weekly for now.
I think this fits under #wave-collect. @trjExpensify, would you agree?
Did we conclude on this? https://github.com/Expensify/App/issues/43508#issuecomment-2163019303
Seems like it would be something we put in #wave-control and track with that to solve allowing anyone that's not the owner to freely leave a workspace.
@johncschuster this issue was created 2 weeks ago. Are we close to a solution? Let's make sure we're treating this as a top priority. Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!
Did we conclude on this? https://github.com/Expensify/App/issues/43508#issuecomment-2163019303
I think we did! @Beamanator, as far as I can tell, this comment is the path forward, right? If so, can you give us a summary?
Nice, ya i think so!
So for the External part of this issue, it looks like basically just want to:
- Give non-owner admins the ability to Leave workspaces
- The "Leave" button should be in the 3-dot menu
Now the possibly interesting thing is: Once we implement this being possible, if a non-owner admin in a Control workspace see a warning about themselves being replaced with the Owner, in every member's policy chain? I kinda assume not, we'll just do that automatically?
@trjExpensify ^^
Given we've come to a conclusion, how about we switch this back to Daily and throw on Help Wanted?
Woof, spotted another thing. I'm an admin non-owner on this workspace and I see the Delete workspace option in NewDot. Only the owner should be able to delete the workspace... 😬
Now the possibly interesting thing is: Once we implement this being possible, if a non-owner admin in a Control workspace see a warning about themselves being replaced with the Owner, in every member's policy chain? I kinda assume not, we'll just do that automatically?
Are we implementing that as part of the approvals logic you're working on? That's why I was kinda' asking whether this should go in #wave-control and be tracked with that project, so it's implemented in tandem.
Are we implementing that as part of the approvals logic you're working on? That's why I was kinda' asking whether this should go in #wave-control and be tracked with that project, so it's implemented in tandem.
Not separately, this should probably all be handled in this issue
Sorry man, what's the tangible difference between a non-owner admin and a member leaving a workspace in this regard? Both user types can be a configured as an approver on the workspace (i.e a configured submitsto, forwardsTo, overLimitForwardsTo). So if we've done the work for the latter to let members leave a workspace as mentioned here, what do we need to do differently in this issue for the warning?
I was basically just asking if we need any difference in warning messages for admins vs non-admins leaving the workspace :D If not, groovy!
Not overdue. Hot Pick was just recently added to the issue. Let's give it a couple days to see if it gets picked up.
I was basically just asking if we need any difference in warning messages for admins vs non-admins leaving the workspace
Can you share the warning message for an admin?
OK so if I understand correctly, here’s what we want:
- Leaving a workspace
- Collect
- NOT ALLOWED if You’re the current manager of any report (a.k.a. if a report has been submitted to you and you’re in line to approve it)
- However, admin can remove you in this case. If you’re the default approver, admin will see warning that you’ll be replaced by owner?
- Otherwise, if you’re the default approver, show warning “Owner will replace you as default approver”
- NOT ALLOWED if You’re the current manager of any report (a.k.a. if a report has been submitted to you and you’re in line to approve it)
- Control
- NOT ALLOWED if You’re the current manager of any report
- However, admin can remove you in this case. If you’re the
submitsToorforwardsTofor anyone in the policy, show warning to admin that you’ll be replaced w/ policy owner
- However, admin can remove you in this case. If you’re the
- Otherwise, if you’re the
submitsToorforwardsToof anyone in the policy, show warning to yourself that you’ll be replaced w/ policy owner- Note: No warning if you’re
overLimitForwardsToor rule approvers (yet), right?
- Note: No warning if you’re
- NOT ALLOWED if You’re the current manager of any report
- Collect
- Deleting a workspace
- Only allowed by workspace Owner
I'll look up the warning message(s) which I think we agreed on in slack, but are the above statements correct? 😅
Hm, why wouldn't we let the current manager of any report leave the workspace? Instead of showing the warning to the admin removing you in that case, we show the warning to the manager leaving.
Huh I might be crazy but i thought we already prevent people from leaving workspaces in that case or some related case, in OldDot - I'll see if I can find what I'm thinking of
Ok I was off a bit - this is what i meant to mention, which is actually "we don't allow removing the default approver from the workspace". I'm not quire sure what we if the default approver is the one trying to leave the workspace
Right, which you're already changing to be a confirmation before updating the default approver to be the workspace admin right?
So to condense this down and bring a consistent implementation across leave/remove and show appropriate errors and confirmations on the NewDot side, I think we can summarise it as follows:
Can leave and can be removed:
- Any member
- Any approver
- Any non-owner admin
Can't leave or can't be removed:
- Workspace owner
- Anyone with an outstanding
processingreport waiting on them to approve - Anyone on a domain that has "prevent workspace creation/removal" enabled
Confirmation modal suggestions:
- If the person trying to leave is an approver, prompt with an alert modal warning on clicking
Leave
Leave workspace If you leave this workspace you will be replaced in the approval workflow with Anthony Davies, the workspace owner.
[Leave workspace] <--- red button [Cancel]
- If the person being removed is an approver, prompt with an alert modal warning on clicking
Remove from workspace.
Remove from workspace If you remove Bob Williams from the workspace, we'll replace them in the approval workflow with Anthony Davies, the workspace owner.
[Remove] <--- red button [Cancel]
- If the person trying to leave has an outstanding
processingreport to action on:
Leave workspace Please approve any outstanding expense reports submitted to you before leaving the workspace. [Got it] <--- Green button
- If the person being removed has an outstanding
processingreport to action on:
Remove from workspace Bob Williams has outstanding expense reports to approve. Ask them to approve, or take control of the reports before removing them from the workspace. [Got it] <--- green button
Additionally, I think there might be a a few more cases to look into to add to the above to round it out completely and not run into errors on NewDot.
- The designated reimburser on the workspace
- The technical contact on the workspace
- The preferred exporter (when connected to an accounting solution)
Feel free to sense check those, but I think we'd handle them as follows:
For 1, let's prevent them from leaving/being removed as there isn't a clean "update to the workspace owner" when leave/removed, as the workspace owner could not have the reimbursement account shared with them.
Confirmation prompts
- If the person trying to leave is the reimburser, prompt with an alert modal warning on clicking
Leave
Leave workspace You can't leave this workspace as the reimburser. Set a new reimburser in Workspaces > [your workspace] > Workflows, and try again.
[Got it] <--- green button
- If the person being removed is the reimburser, prompt with an alert modal warning on clicking
Remove from workspace.
Remove from workspace You can't remove Bob Williams from the workspace. Set a new reimburser in Workspaces > [your workspace] > Workflows, and try again.
[Got it] <--- green button
For 2 & 3, seems straightforward to update to the workspace owner upon leave/removed, because the owner will always be eligible as an admin to take on this role as the technical contact or preferred exporter.
Confirmation prompts
- If the person trying to leave is the technical contact or preferred exporter, prompt with an alert modal warning on clicking
Leave
Leave workspace as technical contact If you leave this workspace you will be replaced as the technical contact with Anthony Davies, the workspace owner.
[Leave workspace] <--- red button [Cancel]
Leave workspace as preferred exporter If you leave this workspace you will be replaced as the preferred exporter with Anthony Davies, the workspace owner.
[Leave workspace] <--- red button [Cancel]
- If the person being removed is the technical contact or preferred exporter, prompt with an alert modal warning on clicking
Remove from workspace.
Remove from workspace as technical contact If you remove Bob Williams from the workspace, we'll replace them as the technical contact with Anthony Davies, the workspace owner.
[Remove] <--- red button [Cancel]
- If the person being removed is the technical contact or preferred exporter, prompt with an alert modal warning on clicking
Remove from workspace.
Remove from workspace as preferred exporter If you remove Bob Williams from the workspace, we'll replace them as the preferred exporter with Anthony Davies, the workspace owner. To choose a different Preferred Exporter, go to the Accounting tab and click on the Export button for your accounting connection.
[Remove] <--- red button [Cancel]
Not overdue. This is actively being discussed.
Right, which you're already changing to be a confirmation before updating the default approver to be the workspace admin right?
I believe you're talking about https://github.com/Expensify/Expensify/issues/404210 or https://github.com/Expensify/App/issues/43885 here, right? So this should already be done
So far I love your Confirmation modal suggestions: section 👍
I think it mayyyy be missing a unique message for the case "Anyone on a domain that has "prevent workspace creation/removal" enabled"?
And as for the designated reimburser / technical contact / preferred exporter (when connected to an accounting solution) I also like those suggestions 👍