[$250] Default workspace name not displayed when moving report

[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.3.33-1
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @parasharrajat
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Create 2 expenses on a non-default workspce
2. open expense report, select any one expense
3. Click Selected > Move to report
4. Choose create report

Expected Result:

Default workspace name displayed when moving report

Actual Result:

Default workspace name not displayed when moving report

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

Screenshots/Videos

08.03.2026_15.32.30_REC.mp4

Recording.2489.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022031065029027547850
• Upwork Job ID: 2031065029027547850
• Last Price Increase: 2026-03-16

[melvin-bot]

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

[MelvinBot]

Proposal

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

When a user selects expenses on a non-default workspace report and uses Selected > Move to report > Create report, the expense is moved to the user's default workspace instead of the workspace shown on the "Create report" option. The UI correctly displays the source workspace name, but the underlying action creates the report on the wrong workspace.

What is the root cause of that problem?

In IOURequestEditReport.tsx:58, the call to usePolicyForMovingExpenses omits the source report's policyID:

usePolicyForMovingExpenses(hasPerDiemTransactions)

The usePolicyForMovingExpenses hook (src/hooks/usePolicyForMovingExpenses.ts:33-82) has a priority chain: (1) use the provided expensePolicyID if valid, (2) fall back to activePolicyID (user's default workspace), (3) single-policy fallback. Since IOURequestEditReport doesn't pass the second argument, the hook skips priority 1 (lines 62-67) and always returns activePolicyID at line 69-71 — the user's default workspace.

Meanwhile, IOURequestEditReportCommon.tsx:90 (which renders the "Create report" button UI) independently calls the same hook WITH selectedReport?.policyID, so the button correctly displays the source workspace name. But this value is only used for display — the actual report creation at IOURequestEditReport.tsx:114-122 uses the wrong policyForMovingExpenses from line 58.

This creates the mismatch: the UI shows workspace B, but the action creates the report on workspace A (the default).

Other callers of the same hook pass the policyID correctly:

• SearchTransactionsChangeReport.tsx:69 — passes selectedReportPolicyID ✅
• IOURequestStepReport.tsx:79 — passes selectedReport?.policyID ?? transactionPolicyID ✅
• IOURequestEditReport.tsx:58 — does not pass policyID ❌

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

In src/pages/iou/request/step/IOURequestEditReport.tsx, line 58, pass selectedReport?.policyID as the second argument to usePolicyForMovingExpenses:

Change from:

usePolicyForMovingExpenses(hasPerDiemTransactions)

to:

usePolicyForMovingExpenses(hasPerDiemTransactions, selectedReport?.policyID)

selectedReport is already loaded at line 41 via useOnyx, so no additional data fetching is needed. This matches the pattern used by SearchTransactionsChangeReport.tsx:69 and IOURequestStepReport.tsx:79.

What alternative solutions did you explore? (Optional)

An alternative would be to have IOURequestEditReport consume the policyForMovingExpenses value from IOURequestEditReportCommon instead of computing its own. However, this would require restructuring the component hierarchy, which is unnecessary since the one-line fix above addresses the root cause directly and matches the established pattern in the other two callers.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[melvin-bot]

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

[melvin-bot]

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

[raju-h]

Proposal

Problem: When moving an expense via Selected > Move to report > Create report on a non-default workspace, the expense lands on the default workspace instead of the one it belongs to.

Root Cause: In src/pages/iou/request/step/IOURequestEditReport.tsx (line 58), the usePolicyForMovingExpenses hook is called without the expense's policyID:

const {policyForMovingExpensesID, shouldSelectPolicy} = usePolicyForMovingExpenses(hasPerDiemTransactions);

The hook's priority chain falls through to the user's activePolicyID (default workspace) because the expensePolicyID parameter is never provided. Meanwhile, the child component IOURequestEditReportCommon.tsx (line 73) does pass selectedReport?.policyID, which is why the button label displays the correct workspace name — but the parent's logic that actually calls createReportForPolicy (line 115-123) uses the wrong policy.

Solution: Pass selectedReport?.policyID as the second argument on line 58:

const {policyForMovingExpensesID, shouldSelectPolicy} = usePolicyForMovingExpenses(hasPerDiemTransactions, selectedReport?.policyID);

selectedReport is already available via useOnyx at line 41. No new data fetching needed.

This matches the pattern used by other callers:

• SearchTransactionsChangeReport.tsx (~line 80) passes selectedReportPolicyID
• IOURequestStepReport.tsx (~line 67) passes selectedReport?.policyID ?? transactionPolicyID

Result: The "Create report" action will correctly use the expense's current workspace instead of the user's default workspace. Display and logic will be consistent.

---

Proposal #2 — paste on [#84635](#84635):

---

Proposal

Problem: Users who are approvers via approval workflows (submitsTo, forwardsTo, overLimitForwardsTo) cannot see the "Top Spenders" insight — only the workspace-level default approver can.

Root Cause: In src/libs/SearchUIUtils.ts (~line 987), the approver check is:

const isApprover = policy.approver === currentUserEmail;

This only matches the workspace's default policy.approver field. Users assigned as approvers through employee-level routing (submitsTo, forwardsTo, overLimitForwardsTo) are missed entirely.

Solution: Replace the inline check with the existing comprehensive utility from src/libs/actions/Policy/Member.ts:

import {isApprover as checkIsApprover} from '@libs/actions/Policy/Member';
// ...
const isApprover = checkIsApprover(policy, currentUserEmail);

This utility already checks policy.approver, plus iterates employeeList for submitsTo, forwardsTo, and overLimitForwardsTo — covering all approval workflow configurations.

Additionally, I'll audit the surrounding insight visibility checks (e.g., "Spend over time") for the same narrow pattern and apply the fix consistently if found.

Known limitation: Tag-based and category-based approval rules (policy.rules?.approvalRules) can also designate approvers. The Policy/Member.ts utility doesn't cover these, but that's a separate enhancement beyond this bug's scope.

Result: All approvers — whether set at the workspace level or via approval workflows — will see the "Top Spenders" insight as intended.

---

Contributor details
Your Expensify account email: rajuhosseng@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~01c9f56cebd089cf23

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!

[jainam884]

🚨 Edited by proposal-police: This proposal was edited at 2026-03-13 10:34:25 UTC.

Proposal

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

When a user moves expenses from a non-default workspace report and opens Selected > Move to report, the Create report row should still represent the default workspace because that is where the new report will be created. Right now the action still creates the report in the default workspace, but the workspace name shown under the Create report row is taken from the source report instead.

What is the root cause of that problem?

IOURequestEditReportCommon is deriving the Create report row label from the selected/source report instead of from the policy that the parent edit flow uses for the actual create action.

In this flow, IOURequestEditReportCommon calls usePolicyForMovingExpenses(isPerDiemRequest, selectedReport?.policyID ?? transactionPolicyID), and because selectedReport?.policyID exists it prefers the source workspace. That value is then rendered as the MenuItem description. But IOURequestEditReport does not pass any explicit display-policy override when it renders the common component, and its own create flow still uses the default workspace path.

App/src/pages/iou/request/step/IOURequestEditReportCommon.tsx

Lines 85 to 90 in 06eb41a

	}, [targetOwnerAccountID, selectedReport?.ownerAccountID, currentUserPersonalDetails.accountID]);
	const reportPolicy = usePolicy(selectedReport?.policyID);
	// Pass the expense's policyID so that the "Create report" button shows the correct workspace
	// instead of defaulting to the user's active workspace
	// we need to fall back to transactionPolicyID because for a new workspace there is no report created yet
	// and if we choose this workspace as participant we want to create a new report in the chosen workspace

App/src/pages/iou/request/step/IOURequestEditReportCommon.tsx

Lines 233 to 243 in 06eb41a

	const createReportOption = useMemo(() => {
	if (!createReport || (isEditing && !isOwner && !isAdmin)) {
	return undefined;
	}
	return (
	<MenuItem
	onPress={handleCreateReport}
	title={translate('report.newReport.createReport')}
	description={policyForMovingExpenses?.name}

App/src/pages/iou/request/step/IOURequestEditReport.tsx

Lines 153 to 161 in 06eb41a

	{CreateReportConfirmationModal}
	<IOURequestEditReportCommon
	backTo={backTo}
	selectedReportID={reportID}
	transactionIDs={selectedTransactionIDs}
	selectReport={selectReport}
	removeFromReport={removeFromReport}
	isEditing={action === CONST.IOU.ACTION.EDIT}
	createReport={createReport}

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

I would keep the create-action behavior unchanged and make the display source explicit for this row.

1. Add an optional prop to IOURequestEditReportCommon, for example createReportPolicyID.
2. Use that prop only for the Create report row description. If it is provided, resolve that policy name for the MenuItem description; otherwise keep the existing behavior.
3. In IOURequestEditReport, pass createReportPolicyID={policyForMovingExpensesID} so the edit flow displays the default workspace name.
4. Leave IOURequestStepReport and SearchTransactionsChangeReport unchanged, since they already intentionally use their current policy context.

const createReportDisplayPolicy = createReportPolicyID
    ? allPolicies?.[`${ONYXKEYS.COLLECTION.POLICY}${createReportPolicyID}`]
    : policyForMovingExpenses;

<MenuItem
    title={translate('report.newReport.createReport')}
    description={createReportDisplayPolicy?.name}
/>

This keeps the fix scoped to the row label instead of changing the shared transactionPolicyID behavior for every caller.

What alternative solutions did you explore? (Optional)

A broader alternative is to change IOURequestEditReportCommon so it stops preferring selectedReport?.policyID and relies only on transactionPolicyID. I think that is riskier because it changes the meaning of an existing prop and forces updates in other flows that are already behaving as intended.