[HOLD for payment 2024-12-30] [$250] Category rule - Approver field is not empty after the approver is removed from the workspace

[IuliiaHerets]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.0.39-0
Reproducible in staging?: Y
Reproducible in production?: Y
Email or phone of affected tester (no customers): applausetester+kh010901@applause.expensifail.com
Issue reported by: Applause Internal Team

Action Performed:

Precondition:

• Rules are enabled.
• "Add approvals" is enabled in Workflows.
• Workspace has at least one member other than yourself.

1. Go to staging.new.expensify.com
2. Go to workspace settings > Categories..
3. Click on any category.
4. Click Approver.
5. Select a member as the approver.
6. Go to Members.
7. Remove the member from the workspace.
8. Go back to the category rule of the category in Step 3.

Expected Result:

Approver field will be empty because the approver is no longer a workspace member.

Actual Result:

Approver field still shows the removed member when the approver is no longer a workspace member.

Workaround:

Unknown

Platforms:

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Bug6610121_1726851329069.20240921_005038.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021854279355604338561
• Upwork Job ID: 1854279355604338561
• Last Price Increase: 2024-11-13
• Automatic offers:
• abzokhattab | Contributor | 105102614

Issue Owner

Current Issue Owner: @mollfpr

[melvin-bot]

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

[IuliiaHerets]

We think that this bug might be related to #wave-control

[IuliiaHerets]

@mallenexpensify FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors

[abzokhattab]

Edited by proposal-police: This proposal was edited at 2024-09-22 11:52:04 UTC.

Proposal

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

The approver field is not empty after the approver is removed from the workspace.

What is the root cause of that problem?

We don't reset the approval rule to be empty after deleting a member.

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

Since we retrieve the category rule in the getCategoryApproverRule function, we can reset the rule.approver property to null if the employee is found to be deleted from the policy's employee list.

To achieve this, we need to add the policyEmployeeList as an additional argument to the getCategoryApproverRule function.
We then use the employee list to check if the approver has been removed:

function getCategoryApproverRule(approvalRules: ApprovalRule[], categoryName: string, policyEmployeeList?: Policy['employeeList']) {
    const approverRule = approvalRules?.find((rule) =>
        rule.applyWhen.find(({condition, field, value}) => condition === CONST.POLICY.RULE_CONDITIONS.MATCHES && field === CONST.POLICY.FIELDS.CATEGORY && value === categoryName),
    );

    if (!approverRule) {
        return null;
    }

    if (policyEmployeeList) {
        const approverPolicyMember = approverRule.approver ? policyEmployeeList?.[approverRule.approver] : null;
        if (!approverPolicyMember || approverPolicyMember?.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE) {
            approverRule.approver = '';
        }
    }
    return approverRule;
}

Next, we need to add the policy.employeeList as an argument here:

App/src/pages/workspace/categories/CategorySettingsPage.tsx

Line 80 in 2fdea82

const categoryApprover = CategoryUtils.getCategoryApproverRule(policy?.rules?.approvalRules ?? [], categoryName)?.approver;

optional: if we want to reset the rule completely in this case, we can return null instead of resetting the approverRule.approver in this case. here is the sudo code for the updated code:

    return approvalRules?.find((rule) =>
        rule.applyWhen.find(({condition, field, value}) => condition === CONST.POLICY.RULE_CONDITIONS.MATCHES && field === CONST.POLICY.FIELDS.CATEGORY && value === categoryName) && 
    (!policyEmployeeList || rule.approver == null || policyEmployeeList[rule.approver]?.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE)
    )

POC

Screen.Recording.2024-09-22.at.1.40.17.PM.mov

What alternative solutions did you explore? (Optional)

Another solution is to implement both frontend and backend changes when removing a member from a workspace:

1. In the remove member request (DeleteMembersFromWorkspace ), the backend should also check if this member is used as an approver in any rules and reset the rule value accordingly.
2. In the frontend, we should set the rule and set the pending fields in the optimisticData, successData, and failureData of the delete member request (DeleteMembersFromWorkspace), ensuring we also handle the offline environment properly.
   PS: the rule info could be fetched from the policy and we can find the approval rule after looping though the rules object (rules.approvalRules) and check if the approver is used in any of them.

[mallenexpensify]

Checking with Tom about quick

[melvin-bot]

@mallenexpensify Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[mallenexpensify]

Posted and bumped in #wave-control room https://expensify.slack.com/archives/C06ML6X0W9L/p1727482508265999?thread_ts=1727123059.243429&cid=C06ML6X0W9L