[Due for payment 2025-09-30] [$250] Expense chats should not be GBRd if all expense reports awaiting approval contain only on-hold expenses

[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: 9.1.89-1
Reproducible in staging?: Y
Reproducible in production?: Y
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: @quinthar
Slack conversation (hyperlinked to channel name): #Convert

Action Performed:

1. Submit expense reports containing only on-hold expenses
2. Login as approver
3. Observe that the associated chat still gets GBRd

Expected Result:

If all of the expenses across all reports awaiting approval are marked as on hold, the chat should not be GBRd.

Actual Result:

Chats are still being GBRd even when every expense in all awaiting approval reports is on hold

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari
• MacOS: Desktop

Platforms Tested:

On which of our officially supported platforms was this issue tested:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

Recording.1472.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021955268048702289702
• Upwork Job ID: 1955268048702289702
• Last Price Increase: 2025-09-09

Issue Owner

Current Issue Owner: @jayeshmangwani

[melvin-bot]

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

[lorretheboy]

Proposal

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

Expense chats should not be GBRd if all expense reports awaiting approval contain only on-hold expenses

What is the root cause of that problem?

The getOutstandingChildRequest function doesn't consider whether all expenses in the report are on hold. When all expenses are on hold, the report shouldn't be considered as having outstanding child requests because there's no action the approver can take.

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

If all expenses in the report are on hold, there's no action the approver can take, so the report should not be considered as having outstanding child requests

    if (shouldBeManuallySubmitted) {
        if (hasOnlyHeldExpenses(iouReport.reportID)) {
            return {
                hasOutstandingChildRequest: false,
            };
        }

        return {
            hasOutstandingChildRequest: true,
        };
    }

App/src/libs/ReportUtils.ts

Lines 10081 to 10086 in 4d41b83

	const shouldBeManuallySubmitted = isPaidGroupPolicyPolicyUtils(policy) && !policy?.harvesting?.enabled;
	if (shouldBeManuallySubmitted) {
	return {
	hasOutstandingChildRequest: true,
	};
	}

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

May need to add test for getOutstandingChildRequest in ReportUtilsTest

What alternative solutions did you explore? (Optional)

NA

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.

[bernhardoj]

Proposal

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

Expense chat still show GBR for approver when all expense is on hold.

What is the root cause of that problem?

GBR shows because iouReportActionToApproveOrPay exists even though hasOutstandingChildRequest from the BE is false.

App/src/libs/ReportUtils.ts

Lines 3630 to 3638 in 5eca224

	if (
	(optionOrReport.hasOutstandingChildRequest === true || iouReportActionToApproveOrPay?.reportActionID) &&
	(policy?.reimbursementChoice !== CONST.POLICY.REIMBURSEMENT_CHOICES.REIMBURSEMENT_NO || !hasOnlyPendingTransactions)
	) {
	return {
	reason: CONST.REQUIRES_ATTENTION_REASONS.HAS_CHILD_REPORT_AWAITING_ACTION,
	reportAction: iouReportActionToApproveOrPay,
	};
	}

Also, for the approver, the RBR doesn't show because it's only shown for submitter.

App/src/libs/ReportUtils.ts

Lines 7983 to 7992 in 5eca224

	function shouldDisplayViolationsRBRInLHN(report: OnyxEntry<Report>, transactionViolations: OnyxCollection<TransactionViolation[]>): boolean {
	// We only show the RBR in the highest level, which is the expense chat
	if (!report || !isPolicyExpenseChat(report)) {
	return false;
	}
	// We only show the RBR to the submitter
	if (!isCurrentUserSubmitter(report)) {
	return false;
	}

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

If we want to show the RBR too for the approver, then we can remove this code.

App/src/libs/ReportUtils.ts

Lines 7989 to 7992 in 5eca224

	// We only show the RBR to the submitter
	if (!isCurrentUserSubmitter(report)) {
	return false;
	}

If we don't want to show either RBR or GBR, then remove the check for iouReportActionToApproveOrPay.

App/src/libs/ReportUtils.ts

Lines 3630 to 3637 in 5eca224

	if (
	(optionOrReport.hasOutstandingChildRequest === true || iouReportActionToApproveOrPay?.reportActionID) &&
	(policy?.reimbursementChoice !== CONST.POLICY.REIMBURSEMENT_CHOICES.REIMBURSEMENT_NO || !hasOnlyPendingTransactions)
	) {
	return {
	reason: CONST.REQUIRES_ATTENTION_REASONS.HAS_CHILD_REPORT_AWAITING_ACTION,
	reportAction: iouReportActionToApproveOrPay,
	};

It was added in #61106. It's trying to fix an issue where if there are multiple reports to approve in a WS chat, approving the last expense will set the hasOutstandingChildRequest to false, but it's not happening anymore, so we can remove it.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

If we choose 1st solution, we can test that shouldDisplayViolationsRBRInLHN returns true for both submitter and approver.

If we choose 2nd solution, we can test that getReasonAndReportActionThatRequiresAttention returns the correct reason when hasOutstandingChildRequest is true.

[melvin-bot]

@sonialiap Still overdue 6 days?! Let's take care of this!

[melvin-bot]

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

[melvin-bot]

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