Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
3 of 6 tasks
IuliiaHerets opened this issue Oct 8, 2024 · 29 comments
Assignees
Labels
Awaiting Payment Auto-added when associated PR is deployed to production Bug Something is broken. Auto assigns a BugZero manager. Daily KSv2 External Added to denote the issue can be worked on by a contributor

Comments

@IuliiaHerets
Copy link

IuliiaHerets commented Oct 8, 2024

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 OwnerCurrent Issue Owner: @strepanier03
@IuliiaHerets IuliiaHerets added Daily KSv2 Bug Something is broken. Auto assigns a BugZero manager. labels Oct 8, 2024
Copy link

melvin-bot bot commented Oct 8, 2024

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
Copy link
Author

@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
Copy link
Contributor

huult commented Oct 9, 2024

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
Copy link
Contributor

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

<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,
    },
};

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

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

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

  1. Then we can return pendingFields here

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

  1. 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)}>

<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

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

@melvin-bot melvin-bot bot added the Overdue label Oct 11, 2024
@strepanier03 strepanier03 added the External Added to denote the issue can be worked on by a contributor label Oct 11, 2024
Copy link

melvin-bot bot commented Oct 11, 2024

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

@melvin-bot melvin-bot bot changed the title Approver - In edit approval workflow, in offline approver selected is not greyed out [$250] Approver - In edit approval workflow, in offline approver selected is not greyed out Oct 11, 2024
@melvin-bot melvin-bot bot added the Help Wanted Apply this label when an issue is open to proposals by contributors label Oct 11, 2024
Copy link

melvin-bot bot commented Oct 11, 2024

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

@strepanier03
Copy link
Contributor

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
Copy link
Contributor

eh2077 commented Oct 14, 2024

@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
Copy link
Contributor

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

@eh2077
Copy link
Contributor

eh2077 commented Oct 14, 2024

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

Copy link

melvin-bot bot commented Oct 14, 2024

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

@huult
Copy link
Contributor

huult commented Oct 14, 2024

@eh2077 Could you review my proposal?

@huult
Copy link
Contributor

huult commented Oct 14, 2024

@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
Copy link
Contributor

huult commented Oct 15, 2024

@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
Copy link
Contributor

eh2077 commented Oct 15, 2024

@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
Copy link
Contributor

huult commented Oct 15, 2024

@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
Copy link
Contributor

flodnv commented Oct 15, 2024

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

@flodnv flodnv removed their assignment Oct 15, 2024
@eh2077
Copy link
Contributor

eh2077 commented Oct 16, 2024

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 melvin-bot bot removed the Help Wanted Apply this label when an issue is open to proposals by contributors label Oct 16, 2024
Copy link

melvin-bot bot commented Oct 16, 2024

📣 @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
Copy link
Contributor

tgolen commented Oct 16, 2024

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

@melvin-bot melvin-bot bot added Reviewing Has a PR in review Weekly KSv2 and removed Daily KSv2 labels Oct 21, 2024
@melvin-bot melvin-bot bot added Weekly KSv2 Awaiting Payment Auto-added when associated PR is deployed to production and removed Weekly KSv2 labels Oct 29, 2024
@melvin-bot melvin-bot bot changed the title [$250] Approver - In edit approval workflow, in offline approver selected is not greyed out [HOLD for payment 2024-11-05] [$250] Approver - In edit approval workflow, in offline approver selected is not greyed out Oct 29, 2024
@melvin-bot melvin-bot bot removed the Reviewing Has a PR in review label Oct 29, 2024
Copy link

melvin-bot bot commented Oct 29, 2024

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

Copy link

melvin-bot bot commented Oct 29, 2024

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:

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

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

Copy link

melvin-bot bot commented Oct 29, 2024

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:

@melvin-bot melvin-bot bot added Daily KSv2 and removed Weekly KSv2 labels Nov 4, 2024
@strepanier03
Copy link
Contributor

strepanier03 commented Nov 5, 2024

Payment Summary

@strepanier03
Copy link
Contributor

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

@eh2077
Copy link
Contributor

eh2077 commented Nov 7, 2024

Checklist

@strepanier03
Copy link
Contributor

Thanks @eh2077 - The payment summary is ready for you here, feel free to request payment :)

@eh2077
Copy link
Contributor

eh2077 commented Nov 8, 2024

Requested payment in NewDot

@JmillsExpensify
Copy link

$250 approved for @eh2077

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Awaiting Payment Auto-added when associated PR is deployed to production Bug Something is broken. Auto assigns a BugZero manager. Daily KSv2 External Added to denote the issue can be worked on by a contributor
Projects
None yet
Development

No branches or pull requests

8 participants