[Due for payment 2025-02-25] [$250] Prevent self approval remains enabled with only one member

[IuliiaHerets]

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: v9.0.96-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail: #55740
Email or phone of affected tester (no customers): [email protected]
Issue reported by: Applause Internal Team
Device used: macOS/chrome
App Component: Workspace Settings

Action Performed:

Prerequisites:

• Control workspace with two members( admin and employee)
• Workflow and Rules are enabled

Steps

1. Go to https://staging.new.expensify.com/ > Sign in
2. Go to Settings > Workspaces > Workflows > Enable approvals
3. Go to Rules section, toggle Prevent Self Approvals. (Self approvals can be enabled because there are at least two members.)
4. Go to members > Remove the employee by clicking the employee and remove it from the opened RHN
5. Go to Rules section. Notice Prevent Self Approvals is still enabled

Expected Result:

Prevent Self Approval is disabled when there is only one member. Self approvals can't be enabled until this workspace has at least two members.

Actual Result:

Prevent Self Approval remains Enabled with only the owner as a member.

Workaround:

Unknown

Platforms:

• Android: Standalone
• Android: HybridApp
• Android: mWeb Chrome
• iOS: Standalone
• iOS: HybridApp
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Bug6739183_1739250164964.Screen_Recording_2025-02-11_at_6.22.09_in_the_morning.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021889681298278222810
• Upwork Job ID: 1889681298278222810
• Last Price Increase: 2025-02-12
• Automatic offers:
• mkzie2 | Contributor | 106109805

Issue Owner

Current Issue Owner: @OfstadC

[melvin-bot]

Triggered auto assignment to @OfstadC (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.

[nyomanjyotisa]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Prevent self approval remains enabled with only one member

What is the root cause of that problem?

The logic to disable the "Prevent self-approvals" toggle based on the member count is only executed at the time the toggle is changed.

App/src/pages/workspace/rules/ExpenseReportRulesSection.tsx

Lines 49 to 60 in 48520ec

	function handleTogglePreventSelfApprovals(isEnabled: boolean) {
	if (!isEnabled) {
	setPolicyPreventSelfApproval(policyID, false);
	return;
	}
	if (selfApproversEmails.length === 0) {
	setPolicyPreventSelfApproval(policyID, true);
	} else {
	setIsPreventSelfApprovalsModalVisible(true);
	}
	}

What changes do you think we should make in order to solve the problem?

We can use useEffect hook that monitors the workspace member count. Whenever the member count drops below 2 and preventSelfApproval is enabled, the effect should automatically disable it by calling setPolicyPreventSelfApproval(policyID, false).

    useEffect(() => {
        if (defaultWorkflowMembers && defaultWorkflowMembers.length < 2 && policy?.preventSelfApproval) {
            setPolicyPreventSelfApproval(policyID, false);
        }
    }, [defaultWorkflowMembers, policy?.preventSelfApproval, policyID]);

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

N/A

What alternative solutions did you explore? (Optional)

N/A

[mkzie2]

🚨 Edited by proposal-police: This proposal was edited at 2025-02-11 15:24:06 UTC.

Proposal

Please re-state the problem that we are trying to solve in this issue.

Prevent Self Approval remains Enabled with only the owner as a member.

What is the root cause of that problem?

We don't have any logic to disable preventSelfApproval after removing the members in the member detail page like we do in WorkspaceMembersPage.

App/src/pages/workspace/WorkspaceMembersPage.tsx

Line 236 in 5b05237

if (newEmployeesCount === 1 && policy?.preventSelfApproval) {

What changes do you think we should make in order to solve the problem?

We need to apply the same logic in WorkspaceMembersPage here

const previousEmployeesCount = Object.keys(policy?.employeeList ?? {}).length;
if (previousEmployeesCount - 1 === 1 && policy?.preventSelfApproval) {
    // We can't let the "Prevent Self Approvals" enabled if there's only one workspace user
    setPolicyPreventSelfApproval(route.params.policyID, false);
}

App/src/pages/workspace/members/WorkspaceMemberDetailsPage.tsx

Line 148 in 5b05237

const removeUser = useCallback(() => {

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

Create a test for removeMembers and assert that preventSelfApproval is updated to false if we only have one member

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[lakchote]

Handling this one as I have worked on the feature.

[lakchote]

@IuliiaHerets I'm unable to reproduce.

See the video test below, on staging:

Screen.Recording.2025-02-11.at.11.29.59.mov

[mkzie2]

@lakchote I still can able to reproduce this one on staging and on the latest main.

Screen.Recording.2025-02-11.at.18.04.00.mov

[lakchote]

I've retested and I'm still not able to reproduce either on staging or main @mkzie2.

What is the result of the API call SetPolicyPreventSelfApproval when you are removing the member?

[mkzie2]

@lakchote To reproduce this one, you should remove the member in the member detail page like I did here #56644 (comment).

It's a frontend issue because we don't have logic to call SetPolicyPreventSelfApproval API in member detail page like we do in the member page. I updated proposal.

[trjExpensify]

Yeah, I think that's right.

Remove from bulk select menu, can't repro:

2025-02-11_16-33-53.mp4

Remove from member details screen, can repro:

2025-02-11_16-35-38.mp4

[lakchote]

Making this External as it can be worked on by contributors and I'm quite busy. There should be unit tests done too like in @mkzie2's proposal.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~021889681298278222810

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @parasharrajat (External)

[lakchote]

@parasharrajat please review @mkzie2's proposal.

[parasharrajat]

@mkzie2's proposal looks good to me. Such actions should be bound to user interactions using effects can be problematic.

🎀 👀 🎀 C+ reviewed

[melvin-bot]

Current assignee @lakchote is eligible for the choreEngineerContributorManagement assigner, not assigning anyone new.

[lakchote]

@mkzie2's proposal LGTM.

[melvin-bot]

📣 @mkzie2 🎉 An offer has been automatically sent to your Upwork account for the Contributor role 🎉 Thanks for contributing to the Expensify app!

Offer link
Upwork job
Please accept the offer and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review 🧑‍💻
Keep in mind: Code of Conduct | Contributing 📖

[mkzie2]

Such actions should be bound to user interactions using effects can be problematic.

I think we don't need this because. I checked the PR #50488 that used the interaction on the member page, it's used to ensure the confirm modal display the correct text before it's closed.

On the member detail page the content in the confirm modal isn't changed so it's unnecessary.

[mkzie2]

Making this External as it can be worked on by contributors and I'm quite busy. There should be unit tests done too like in @mkzie2's proposal.

I forgot to remove this section when I updated my proposal. With the new proposal, we update the Prevent Self-Approvals in the UI so I don't think we need to add the test here

[mkzie2]

@parasharrajat The PR is ready.

[lakchote]

PR has been merged.

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.0.99-2 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• fix: prevent selfApproval isn't disabled when removing member from the detail page #56896

If no regressions arise, payment will be issued on 2025-02-25. 🎊

For reference, here are some details about the assignees on this issue:

• @parasharrajat requires payment through NewDot Manual Requests
• @mkzie2 requires payment automatic offer (Contributor)

[melvin-bot]

@parasharrajat @OfstadC @parasharrajat The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]

[parasharrajat]

BugZero Checklist:

• [Contributor] Classify the bug:

Bug classification

Source of bug:

• 1a. Result of the original design (eg. a case wasn't considered)
• 1b. Mistake during implementation
• 1c. Backend bug
• 1z. Other:

Where bug was reported:

• 2a. Reported on production (eg. bug slipped through the normal regression and PR testing process on staging)
• 2b. Reported on staging (eg. found during regression or PR testing)
• 2d. Reported on a PR
• 2z. Other:

Who reported the bug:

• 3a. Expensify user
• 3b. Expensify employee
• 3c. Contributor
• 3d. QA
• 3z. Other:

• [Contributor] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake.

  Link to comment: Prevent self approvals #55740 (comment)

• [Contributor] If the regression was CRITICAL (e.g. interrupts a core flow) A discussion in #expensify-open-source has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner.

  Link to discussion: Not needed

• [Contributor] If it was decided to create a regression test for the bug, please propose the regression test steps using the template below to ensure the same bug will not reach production again.

• [BugZero Assignee] Create a GH issue for creating/updating the regression test once above steps have been agreed upon.

  Link to issue: https://github.com/Expensify/Expensify/issues/474103

Regression Test Proposal

Precondition:

• The workspace has enabled the rule, workflow, and approval feature. It only has 2 members

Test:

1. Login as the owner of the workspace.
2. Add more than 2 members.
3. Go the the workspace > Rule.
4. Enable Prevent self-approvals
5. Go to the members list page.
6. Open the detail page of a member.
7. Remove member.
8. Continue this process until one member is left.
9. Open the rule page again and verify that Prevent self-approvals is disabled

Do we agree 👍 or 👎

[OfstadC]

Payment Summary

• @parasharrajat due $250 via manual NewDot request
• @mkzie2 paid $250 via Upwork

[parasharrajat]

Payment requested as per #56644 (comment)

[JmillsExpensify]

$250 approved for @parasharrajat