[HOLD for payment 2024-06-06] [$250] Wrong "Next step" displayed for the approver

[m-natarajan]

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: 1.4.70-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
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: @JmillsExpensify
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1714518611299619

Action Performed:

Prerequisite: Have a collect workspace with admin, approver, and employee.

1. Employee submits report to approver
2. Approver approves the report
3. Observe the next step header for approver

Expected Result:

"Waiting for you to pay these expenses" should not be displayed for the approver

Actual Result:

"Waiting for you to pay these expenses" is displayed for approver who is not configured to pay the report

Workaround:

Unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

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

Screenshots/Videos

Add any screenshot/video evidence

pay.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01e9b6cf8e506af2ea
• Upwork Job ID: 1787692015561465856
• Last Price Increase: 2024-05-07
• Automatic offers:
• dukenv0307 | Reviewer | 0

Issue Owner

Current Issue Owner: @adelekennedy

[melvin-bot]

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

[cretadn22]

Proposal

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

Payer is wrong in the header

What is the root cause of that problem?

When an employee creates a money request, the backend returns a request report where the managerID is the ID of the approver

App/src/libs/NextStepUtils.ts

Lines 302 to 309 in 2f5173c

	if (!isOwner) {
	optimisticNextStep.message = [
	{
	text: 'Waiting for ',
	},
	{
	text: managerDisplayName,
	type: 'strong',

Given that managerDisplayName is "you"

If I understand correctly:

• ownerID corresponds to the ID of the request creator
• managerID corresponds to the ID of the workspace admin

If this understanding is accurate, then the current logic here is wrong

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

We need to extract the approverID from the policy using approverID = policy.submitsTo. Then

• If the current user is the approver, we'll show "you"
• If the current user isn't the approver, we'll display the name of the approver

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.

[melvin-bot]

@adelekennedy Whoops! This issue is 2 days overdue. Let's get this updated quick!

[melvin-bot]

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

[melvin-bot]

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

[adelekennedy]

@dukenv0307 just one proposal to review so far

[dominictb]

Proposal

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

"Waiting for you to pay these expenses" is displayed for approver who is not configured to pay the report

What is the root cause of that problem?

The logic we have here is wrong, in this case there's no further action required from the approver so the message shown is incorrect

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

Since there's no further action required from the approver in this case, we can update this to the No further action required! next step like in here, this is also consistent with what the back-end returns.

Or we can use the no action required message for the whole block here (except the case where the current user is the payer of the request too)

What alternative solutions did you explore? (Optional)

Early return No further action required! next step in here if the current user cannot pay the request (eg. Is not one of the workspace admins, the full condition for checking if user can pay the request is here and !ReportUtils.isInvoiceReport here)

[dukenv0307]

starting review now

[dukenv0307]

I like @dominictb's alternative solution

🎀👀🎀 C+ reviewed

[melvin-bot]

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

[trjExpensify]

@mountiny fancy giving this proposal a review?

[melvin-bot]

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

Offer link
Upwork job

[melvin-bot]

📣 @dominictb You have been assigned to this job!
Please apply to the Upwork job and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review 🧑‍💻
Once you apply to this job, your Upwork ID will be stored and you will be automatically hired for future jobs!
Keep in mind: Code of Conduct | Contributing 📖

[mountiny]

Happy to take this over from Flo as I have worked on the next steps before.

@dominictb Your alternative solution looks better. When the isOwner condition was implemented, we still did not have the policy reimburser data in the App or policy settings. Now, we should use the method you have mentioned in the alternative solutions or the isPayer logic, needs to be checked thoroughly. This should ensure the payer will get this message correctly.

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

• fix: update next step for approver #42018

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

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

• @dukenv0307 requires payment automatic offer (Reviewer)
• @dominictb requires payment (Needs manual offer from BZ)

[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:

• [@dukenv0307] The PR that introduced the bug has been identified. Link to the PR:
• [@dukenv0307] 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:
• [@dukenv0307] 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:
• [@dukenv0307] Determine if we should create a regression test for this bug.
• [@dukenv0307] 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.
• [@adelekennedy] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[adelekennedy]

@dominictb do you mind applying to the job here so I can pay you out? Thank you!!

[adelekennedy]

@dominictb accepted

[dominictb]

@adelekennedy Offer accepted, thanks

[adelekennedy]

payments made! @dukenv0307 do we need a regression test here?

[dukenv0307]

BugZero Checklist:

• The PR that introduced the bug has been identified. Link to the PR: N/A
• 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: N/A
• 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: N/A
• Determine if we should create a regression test for this bug. N/A
• 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. N/A