[HOLD for payment 2024-01-18] [HOLD for payment 2024-01-17] Scan - No red dot for Amount and Merchant when viewing failed scan request as Admin

[lanitochka17]

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: 1.4.23-0
Reproducible in staging?: Y
Reproducible in production?: N
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: Applause - Internal Team
Slack conversation:

Action Performed:

1. [Member] Go to workspace chat.
2. [Member] Create scan request with receipt that will fail the scanning.
3. [Admin] When the scanning fails, navigate to the workspace chat with member.
4. [Admin] Open the request details view.

Expected Result:

Admin sees red dot for empty Amount and Merchant row

Actual Result:

There is no red dot for Amount and Merchant when viewing as Admin

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

Bug6337006_1704825645047.20240110_010236__1_.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~0131c5620c048a6293
• Upwork Job ID: 1744814084372897792
• Last Price Increase: 2024-01-09

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[melvin-bot]

Triggered auto assignment to @arosiclair (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

[s-alves10]

Proposal

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

No red dot for amount and merchant appear when admin viewing failed scan request

What is the root cause of that problem?

This looks like a regression of this PR #33633

We check the editability of the receipt here

App/src/libs/ReportUtils.ts

Lines 1950 to 1953 in 5df6055

	if (fieldToEdit === CONST.EDIT_REQUEST_FIELD.RECEIPT) {
	const isRequestor = currentUserAccountID === reportAction?.actorAccountID;
	return !TransactionUtils.isReceiptBeingScanned(transaction) && !TransactionUtils.isDistanceRequest(transaction) && isRequestor;
	}

As you can see, only requestor can edit the request. So the admin can't edit the request and canEditReceipt will be false

App/src/components/ReportActionItem/MoneyRequestView.js

Line 161 in 5df6055

const canEditReceipt = ReportUtils.canEditFieldOfMoneyRequest(parentReportAction, CONST.EDIT_REQUEST_FIELD.RECEIPT);

So hasErrors will be false as well.

App/src/components/ReportActionItem/MoneyRequestView.js

Line 225 in 5df6055

hasErrors = canEditReceipt && TransactionUtils.hasMissingSmartscanFields(transaction);

This is the root cause

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

I think the admin or manager should be able to edit the scan request as well

Update the code

App/src/libs/ReportUtils.ts

Lines 1950 to 1953 in 5df6055

	if (fieldToEdit === CONST.EDIT_REQUEST_FIELD.RECEIPT) {
	const isRequestor = currentUserAccountID === reportAction?.actorAccountID;
	return !TransactionUtils.isReceiptBeingScanned(transaction) && !TransactionUtils.isDistanceRequest(transaction) && isRequestor;
	}

to

    if (fieldToEdit === CONST.EDIT_REQUEST_FIELD.RECEIPT) {
        const isRequestor = currentUserAccountID === reportAction?.actorAccountID;
        return !TransactionUtils.isReceiptBeingScanned(transaction) && !TransactionUtils.isDistanceRequest(transaction) && (isRequestor || isAdmin || isManager);
    }

isAdmin and isManager are defined as

App/src/libs/ReportUtils.ts

Lines 1942 to 1944 in 5df6055

	const policy = getPolicy(moneyRequestReport?.reportID ?? '');
	const isAdmin = isExpenseReport(moneyRequestReport) && policy.role === CONST.POLICY.ROLE.ADMIN;
	const isManager = isExpenseReport(moneyRequestReport) && currentUserAccountID === moneyRequestReport?.managerID;

Result

What alternative solutions did you explore? (Optional)

[youssef-lr]

@s-alves10 that would allow the admin to edit a receipt, we decided in the past that there are no use cases for an admin or manager to update the receipt of the request.

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to Contributor Plus for review of internal employee PR - @akinwale (Internal)

[s-alves10]

we decided in the past that there are no use cases for an admin or manager to update the receipt of the request

If so, I think this isn't a bug and we can close this out

[youssef-lr]

I need to double check whether we want to display errors for the admin still, can be fixed by just removing canEditReceipt from here hasErrors = canEditReceipt && TransactionUtils.hasMissingSmartscanFields(transaction);

[youssef-lr]

Sorry my bad here, I shouldn't have changed canEdit to canEditReceipt in that line in my PR. Raising a PR now.

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[thienlnam]

Looks like a fix was merged but I'll ask to get it CPed so we can get rid of the blocker

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

• Allow admins/managers to see RBR errors on reports #34195

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

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

• @akinwale requires payment (Needs manual offer from BZ)

[melvin-bot]

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

• Allow admins/managers to see RBR errors on reports #34195

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

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

• @akinwale requires payment (Needs manual offer from BZ)

[youssef-lr]

No payment needed here.