[HOLD for payment 2024-11-05] [$250] Approver - In edit approval workflow, in offline approver selected is not greyed out

[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.46-3
Reproducible in staging?: Y
Reproducible in production?: Y
Issue reported by: Applause Internal Team

Action Performed:

Pre-condition:

1. Launch app
2. Tap profile icon -- workspaces -- workspace
3. Tap more features -- enable workflows -- enable add approval
4. Go offline
5. Tap approver - select a member - save

Expected Result:

In edit approval workflow, in offline approver selected must be greyed out.

Actual Result:

In edit approval workflow, in offline approver selected is not greyed out.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug6628543_1728406287719.Screenrecorder-2024-10-08-17-31-14-150_compress_1.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021844825382815760064
• Upwork Job ID: 1844825382815760064
• Last Price Increase: 2024-10-11
• Automatic offers:
• nkdengineer | Contributor | 104447976

Issue Owner

Current Issue Owner: @strepanier03

[melvin-bot]

Triggered auto assignment to @strepanier03 (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]

@strepanier03 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

[huult]

Edited by proposal-police: This proposal was edited at 2024-10-09 09:27:42 UTC.

Proposal

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

In edit approval workflow, in offline approver selected is not greyed out

What is the root cause of that problem?

We haven't handled the case for greying out the edit approval workflow yet

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

We need to wrap the component rendering members and approver with OfflineWithFeedback, something like this

+ const approvalWorkflowPendingUpdate = approvalWorkflow.pendingAction;
// .src/pages/workspace/workflows/approvals/ApprovalWorkflowEditor.tsx#L136
+                        <OfflineWithFeedback pendingAction={approvalWorkflowPendingUpdate>
                            <MenuItemWithTopDescription
                             ....
                            />
+                        </OfflineWithFeedback>

// .src/pages/workspace/workflows/approvals/ApprovalWorkflowEditor.tsx#L151
+                        <OfflineWithFeedback pendingAction={approvalWorkflowPendingUpdate}>
                            <MenuItemWithTopDescription
                             ....
                            />
+                        </OfflineWithFeedback>

// .src/pages/workspace/workflows/approvals/ApprovalWorkflowEditor.tsx#L198
+                        <OfflineWithFeedback pendingAction={approvalWorkflowPendingUpdate}>
                            <MenuItemWithTopDescription
                             ....
                            />
+                        </OfflineWithFeedback>

What alternative solutions did you explore? (Optional)

If we want to gray out only the edited parts, you need to check which members or approver changed and then gray them out. Some thing like that:

// .src/pages/workspace/workflows/approvals/ApprovalWorkflowEditor.tsx#L103
// get list employee pending update
+   const [listEmployeePending, setListEmployeePending] = useState<[]>();
+ const getFieldPending = useCallback(async () => {
+        try {
+            const persistedRequests = await PersistedRequests.getAll();
+            const updateWorkspaceApprovalRequests = persistedRequests.filter(({command}) => command === WRITE_COMMANDS.UPDATE_WORKSPACE_APPROVAL);
+            const employeesPending = updateWorkspaceApprovalRequests.flatMap((item) => {
+                const employees = JSON.parse(item.data.employees);
+                return employees.filter((employee) => employee.pendingAction === 'update');
+            });
+            setListEmployeePending(employeesPending);
+        } catch (error) {
+            console.error('****** error ******', error);
+        }
+    }, []);

+    useEffect(() => {
+        getFieldPending();
+    }, [getFieldPending]);

// .src/pages/workspace/workflows/approvals/ApprovalWorkflowEditor.tsx#L173
// We check if this approver's pendingAction is 'update' or not
+  const isApproverPending = (listEmployeePending || []).some((item) => {
+                        return item.email === approver?.email;
+                    });
 // .src/pages/workspace/workflows/approvals/ApprovalWorkflowEditor.tsx#L178        
 // Update condition to show grayed out           
+                <OfflineWithFeedback pendingAction={isApproverPending ? approvalWorkflowPendingUpdate : undefined}>
                      <MenuItemWithTopDescription
                           ....

POC

Screen.Recording.2024-10-09.at.16.17.45.mov

[nkdengineer]

Proposal

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

In edit approval workflow, in offline approver selected is not greyed out.

What is the root cause of that problem?

We don't add OfflineWithFeedback here

App/src/pages/workspace/workflows/approvals/ApprovalWorkflowEditor.tsx

Lines 137 to 139 in 285bde8

	<MenuItemWithTopDescription
	// eslint-disable-next-line react/no-array-index-key
	key={`approver-${approver?.email}-${approverIndex}`}

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

1. When we update the workflow, we can update the pendingFields of each updated employee

updatedEmployeeList[approver.email] = {
    email: approver.email,
    forwardsTo,
    pendingAction,
    pendingFields: {
        forwardsTo: pendingAction,
    },
};

App/src/libs/WorkflowUtils.ts

Lines 233 to 237 in 285bde8

	updatedEmployeeList[approver.email] = {
	email: approver.email,
	forwardsTo,
	pendingAction,
	};

updatedEmployeeList[email] = {
    ...(updatedEmployeeList[email] ? updatedEmployeeList[email] : {email}),
    submitsTo,
    pendingAction,
    pendingFields: {
        submitsTo: pendingAction,
    },
};

App/src/libs/WorkflowUtils.ts

Lines 249 to 253 in 285bde8

	updatedEmployeeList[email] = {
	...(updatedEmployeeList[email] ? updatedEmployeeList[email] : {email}),
	submitsTo,
	pendingAction,
	};

2. Then we can return pendingFields here

App/src/libs/WorkflowUtils.ts

Lines 124 to 127 in 285bde8

	const member: Member = {
	email,
	avatar: personalDetailsByEmail[email]?.avatar,
	displayName: personalDetailsByEmail[email]?.displayName ?? email,

3. We will create a function to get the pendingAction for each approver. For the first approver, it's pending if any member in the workflow has pendingFields.submitsTo. For each other approver, it's pending if the previous approver has pendingFields.forwardsTo because if this approver is updated the forwardsTo of the previous approver will be updated

const getApprovalPendingAction = useCallback(
    (index: number) => {
        let pendingAction: PendingAction | undefined;
        if (index === 0) {
            approvalWorkflow?.members?.forEach((member) => {
                pendingAction = pendingAction ?? member.pendingFields?.submitsTo;
            });
            return pendingAction;
        }
        const previousApprover = approvalWorkflow?.approvers.at(index - 1);
        const previousMember = approvalWorkflow?.members?.find((member) => member?.email === previousApprover?.email);
        return previousMember?.pendingFields?.forwardsTo;
    },
    [approvalWorkflow],
);

<OfflineWithFeedback pendingAction={getApprovalPendingAction(approverIndex)}>

App/src/pages/workspace/workflows/approvals/ApprovalWorkflowEditor.tsx

Lines 137 to 139 in 285bde8

	<MenuItemWithTopDescription
	// eslint-disable-next-line react/no-array-index-key
	key={`approver-${approver?.email}-${approverIndex}`}

What alternative solutions did you explore? (Optional)

We can wrap OfflineWithFeedback for each approver with pendingAction is approvalWorkflow.pendingAction

App/src/pages/workspace/workflows/approvals/ApprovalWorkflowEditor.tsx

Lines 137 to 139 in 285bde8

	<MenuItemWithTopDescription
	// eslint-disable-next-line react/no-array-index-key
	key={`approver-${approver?.email}-${approverIndex}`}

[melvin-bot]

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

[melvin-bot]

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

[strepanier03]

Not 100% sure about the Project since there's a shift internally and I don't think things are updated fully. It might move but for now we can work on this.

[eh2077]

@nkdengineer Thanks for your proposal. Your alternative solution looks simpler and it's same as the main solution of the first proposal. Is there any drawback of the alternative solution? Or what're the advantages of your main solution?

[nkdengineer]

@eh2077 With my main solution, only the changed approver will be grey out instead of all approvers as my alternative solution.

[eh2077]

I think this shouldn't be a recent bug but a missing case we want to polish.

@nkdengineer 's proposal looks good to me.

🎀👀🎀 C+ reviewed

[melvin-bot]

Triggered auto assignment to @flodnv, see https://stackoverflow.com/c/expensify/questions/7972 for more details.

[huult]

@eh2077 Could you review my proposal?

[huult]

@eh2077 , My proposal provides two solutions:

• Main solution: This will gray out all members and approver, similar to the alternative solution in the other proposal.
• Alternative solution: This will gray out only the field that was changed, similar to the main solution in the other proposal. However, my proposal provides a simpler code example and also resolves the issue.

and We need to check which of the two solutions to apply to fix this issue. If we gray out only the field that was changed, it won't be consistent with the previous behavior, as it grayed out two fields. We need to confirm this.

[huult]

@eh2077 , I believe both proposals suggest the same solution, differing only in their implementation approach: my proposal checks for approver pending status in the persistent request, while the other proposal sets the pending action in the parameters. Since my proposal came first, I believe the other proposal does not align with the following point from CONTRIBUTING.md

Note: Before submitting a proposal on an issue, be sure to read any other existing proposals. ALL NEW PROPOSALS MUST BE DIFFERENT FROM EXISTING PROPOSALS. The difference should be important, meaningful or considerable.

Once again, I apologize if I'm wrong.

[eh2077]

@huult Thanks for your comments! I did check your proposal

• The main solution to gray out all approvers are not ideal
• While the alternative solution fixes the effect, I think using low level API PersistedRequests.getAll() to extract pending actions isn't the best practice to solve offline UX related issues.

I totally feel your point about competing proposals. I think your proposal is very close to succeed - you included both a simple / straightforward method and a more thoughtful one. If I could give you an advice, I think you can explore the codebase for similar patterns / practices to compare with the solution you come up. Hope it helps, thanks.

[huult]

@eh2077 , Thank you for your feedback and advice.

Would it be alright if I asked you a question?

Regarding the solution, is my proposal still correct? Is my proposal not selected because the code example change isn’t best practice and cannot be updated during the PR phase?

[flodnv]

@tgolen I believe you've recently shipped this feature, so I'm reassigning this to you

[eh2077]

Is my proposal not selected because the code example change isn’t best practice and cannot be updated during the PR phase?

@huult I voted for the other proposal because I think their method is better. I could also be wrong. So, let's wait for @tgolen 's review.

[melvin-bot]

📣 @nkdengineer 🎉 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 📖

[tgolen]

I agree with @eh2077's reasoning for the proposal that was accepted.

[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.54-11 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• fix: in offline approver selected is not greyed out #50991

If no regressions arise, payment will be issued on 2024-11-05. 🎊

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

• @eh2077 requires payment through NewDot Manual Requests
• @nkdengineer requires payment automatic offer (Contributor)

[melvin-bot]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [@eh2077] The PR that introduced the bug has been identified. Link to the PR:
• [@eh2077] 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:
• [@eh2077] A discussion in #expensify-bugs 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:
• [@eh2077] Determine if we should create a regression test for this bug.
• [@eh2077] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [@strepanier03] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[strepanier03]

HOLD FOR CHECKLIST

Payment Summary

• $250 - @nkdengineer PAID via Upwork (contract)
• $250 - @eh2077 via New Expensify manual request

[strepanier03]

@nkdengineer - I have paid and closed the contract for you in Upwork, thank you for continuing to be part of our community.

@eh2077 the payment summary is ready but on hold. Once you do the checklist I'll finish up my bits and update it. I'll check in again later today.