[$500] Clean up duplicated create expense navigation logic

[neil-marcellini]

Problem

If you search the codebase for this comment "If a reportID exists in the report object, it's because either", then you will see that the comment and associated large code block are repeated about 5 times. Duplicated code is likely to cause inconsistencies and bugs, and makes it difficult to read.

Solution

Consolidate that code block, or potentially more if appropriate, into a well named function that can be re-used.

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021960040763246044885
• Upwork Job ID: 1960040763246044885
• Last Price Increase: 2026-01-29
• Automatic offers:
• rohit9625 | Contributor | 108718330

Issue Owner

Current Issue Owner: @

Issue Owner

Current Issue Owner: @

Issue Owner

Current Issue Owner: @RachCHopkins

[melvin-bot]

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

[melvin-bot]

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

[PiyushChandra17]

🚨 Edited by proposal-police: This proposal was edited at 2025-08-26 10:29:03 UTC.

Proposal

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

Clean up duplicated create expense navigation logic

What is the root cause of that problem?

No root cause, It's a duplicated code clean up

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

Already mentioned in OP:

1. Refactor that code block
2. Create a well named function that can be re-used if need be
3. This part is repeated 4 times in our codebase

 // If a reportID exists in the report object, it's because either:
        // - The user started this flow from using the + button in the composer inside a report.
        // - The user started this flow from using the global create menu by selecting the Track expense option.
        // In this case, the participants can be automatically assigned from the report and the user can skip the participants step and go straight
        // to the confirm step.
        // If the user is started this flow using the Create expense option (combined submit/track flow), they should be redirected to the participants page.
        if (report?.reportID && !isArchivedReport(reportNameValuePairs) && iouType !== CONST.IOU.TYPE.CREATE) {
            const selectedParticipants = getMoneyRequestParticipantsFromReport(report);
            const participants = selectedParticipants.map((participant) => {
                const participantAccountID = participant?.accountID ?? CONST.DEFAULT_NUMBER_ID;
                return participantAccountID ? getParticipantsOption(participant, personalDetails) : getReportOption(participant, reportAttributesDerived);
            });

4. We need to create a common function named probably something like handleReportIDFlow or whatever and call/invoke that function in all the 4 places here

5. Move the repeated logic into a common utility function handleReportIDFlow, this function should:

• Accept all the necessary parameters like report, iouType, amount etc
• Encapsulate the participant extraction and conditional logic which is required
• Invoke the correct action like sendMoneyWithWallet, trackExpense etc
• Return early or provide a callback to continue the flow

Replace this duplicated code block in all 4 files, entire code block

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

Lines 180 to 241 in 06dd20e

	// If a reportID exists in the report object, it's because either:
	// - The user started this flow from using the + button in the composer inside a report.
	// - The user started this flow from using the global create menu by selecting the Track expense option.
	// In this case, the participants can be automatically assigned from the report and the user can skip the participants step and go straight
	// to the confirm step.
	// If the user is started this flow using the Create expense option (combined submit/track flow), they should be redirected to the participants page.
	if (report?.reportID && !isArchivedReport(reportNameValuePairs) && iouType !== CONST.IOU.TYPE.CREATE) {
	const selectedParticipants = getMoneyRequestParticipantsFromReport(report);
	const participants = selectedParticipants.map((participant) => {
	const participantAccountID = participant?.accountID ?? CONST.DEFAULT_NUMBER_ID;
	return participantAccountID ? getParticipantsOption(participant, personalDetails) : getReportOption(participant, reportAttributesDerived);
	});
	const backendAmount = convertToBackendAmount(Number.parseFloat(amount));
	if (shouldSkipConfirmation) {
	if (iouType === CONST.IOU.TYPE.PAY || iouType === CONST.IOU.TYPE.SEND) {
	if (paymentMethod && paymentMethod === CONST.IOU.PAYMENT_TYPE.EXPENSIFY) {
	sendMoneyWithWallet(report, backendAmount, currency, '', currentUserPersonalDetails.accountID, participants.at(0) ?? {});
	return;
	}
	sendMoneyElsewhere(report, backendAmount, currency, '', currentUserPersonalDetails.accountID, participants.at(0) ?? {});
	return;
	}
	if (iouType === CONST.IOU.TYPE.SUBMIT || iouType === CONST.IOU.TYPE.REQUEST) {
	requestMoney({
	report,
	participantParams: {
	participant: participants.at(0) ?? {},
	payeeEmail: currentUserPersonalDetails.login,
	payeeAccountID: currentUserPersonalDetails.accountID,
	},
	transactionParams: {
	amount: backendAmount,
	currency,
	created: transaction?.created ?? '',
	merchant: CONST.TRANSACTION.PARTIAL_TRANSACTION_MERCHANT,
	attendees: transaction?.comment?.attendees,
	},
	backToReport,
	shouldGenerateTransactionThreadReport,
	});
	return;
	}
	if (iouType === CONST.IOU.TYPE.TRACK) {
	trackExpense({
	report,
	isDraftPolicy: false,
	participantParams: {
	payeeEmail: currentUserPersonalDetails.login,
	payeeAccountID: currentUserPersonalDetails.accountID,
	participant: participants.at(0) ?? {},
	},
	transactionParams: {
	amount: backendAmount,
	currency: currency ?? 'USD',
	created: transaction?.created,
	merchant: CONST.TRANSACTION.PARTIAL_TRANSACTION_MERCHANT,
	},
	});
	return;
	}
	}

if (report?.reportID && !isArchivedReport(reportNameValuePairs) && iouType !== CONST.IOU.TYPE.CREATE) {
    const selectedParticipants = getMoneyRequestParticipantsFromReport(report);
    // ... map participants, handle shouldSkipConfirmation, call actions, etc.
}

with,

import {handleReportIDFlow} from '@libs/IOUUtils';

handleReportIDFlow({
            report,
            reportNameValuePairs,
            iouType,
            amount,
            paymentMethod,
            currency,
            transaction,
            transactionID,
            currentUserPersonalDetails,
            personalDetails,
            reportAttributesDerived,
            shouldSkipConfirmation,
            shouldGenerateTransactionThreadReport,
            backToReport,
            isSplitBill,
        });

Test thoroughly since this logic this critical to IOU/money request flow, test all the scenarios like iouType, archivedReport etc to ensure the behaviour is consistent throughout

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

n/A

What alternative solutions did you explore? (Optional)

n/A

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.

[github-actions]

⚠️ @PiyushChandra17 Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).

[sofi-a]

🚨 Edited by proposal-police: This proposal was edited at 2025-08-27 02:21:13 UTC.

Proposal

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

Clean up duplicated create expense navigation logic

What is the root cause of that problem?

The comment in the OP can be found in the following components:

• IOURequestStepAmount
• IOURequestStepDistance
• IOURequestStepScan (native version)

The code block inside all components is different, depending on the type of IOU request. Out of the 3 components, IOURequestStepScan contains 100% duplicated code, as both handle scan requests on different platforms, although the following few lines seem to be common in all components.

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

Lines 186 to 191 in bf27e9b

	if (report?.reportID && !isArchivedReport(reportNameValuePairs) && iouType !== CONST.IOU.TYPE.CREATE) {
	const selectedParticipants = getMoneyRequestParticipantsFromReport(report);
	const participants = selectedParticipants.map((participant) => {
	const participantAccountID = participant?.accountID ?? CONST.DEFAULT_NUMBER_ID;
	return participantAccountID ? getParticipantsOption(participant, personalDetails) : getReportOption(participant, reportAttributesDerived);
	});

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

We can create functions in IOUUtils that handle the different request types.

1. Create a function canUseReportParticipants, that wraps the expression in the if statement. This is actually what the comment in the OP pertains to.

// If a reportID exists in the report object, it's because either:
// - The user started this flow from using the + button in the composer inside a report.
// - The user started this flow from using the global create menu by selecting the Track expense option.
// In this case, the participants can be automatically assigned from the report and the user can skip the participants step and go straight
// to the confirm step.
// If the user is started this flow using the Create expense option (combined submit/track flow), they should be redirected to the participants page.
function canUseReportParticipants(report, reportNameValuePairs, iouType) {
  return report?.reportID && !isArchivedReport(reportNameValuePairs) && iouType !== CONST.IOU.TYPE.CREATE;
}

2. Create a function getParticipantsFromReport.

function getParticipantsFromReport(report: Report, personalDetails: PersonalDetails, reportAttributesDerived: ReportAttributesDerived) {
    const selectedParticipants = getMoneyRequestParticipantsFromReport(report);
    return selectedParticipants.map((participant) => {
        const participantAccountID = participant?.accountID ?? CONST.DEFAULT_NUMBER_ID;
        return participantAccountID ? getParticipantsOption(participant, personalDetails) : getReportOption(participant, reportAttributesDerived);
    });
}

3. Create a function handleScanRequest inside a new module at src/pages/iou/request/step/IOURequestStepScan.

function handleScanRequest(scanRequestParams: ScanRequestParams): void;

4. Refactor all components to utilize the new functions.

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

N/A

What alternative solutions did you explore? (Optional)

N/A

[github-actions]

⚠️ @marufsharifi Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.

[TaduJR]

Proposal

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

The codebase contains duplicated navigation logic for creating expenses across multiple files (IOURequestStepAmount.tsx, IOURequestStepDistance.tsx, OURequestStepScan/index.tsx, and IOURequestStepScan/index.native.tsx). This block of code that starts with the comment "If a reportID exists in the report object, it's because either" is repeated in at least 4 locations with slight variations, leading to maintainability issues and potential inconsistencies.

What is the root cause of that problem?

The root cause is the lack of abstraction for the common navigation pattern. When implementing the create expense flow from different entry points (Amount, Distance, Scan), developers copied and modified the same logic instead of extracting it into a reusable function. This violates the DRY (Don't Repeat Yourself) principle and creates technical debt where any future changes need to be made in multiple places.

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

1. Create a new utility function handleExpenseNavigation in a shared location (e.g., src/libs/actions/IOU.ts or a new file src/libs/IOUNavigationUtils.ts)
2. Extract the common logic that:
   - Checks if a reportID exists and determines navigation flow
   - Gets participants from the report
   - Maps participants to the appropriate options format
   - Handles different IOU types (TRACK, SUBMIT, REQUEST, PAY, SEND, SPLIT) with their specific actions
3. Replace all duplicated code blocks with calls to this new utility function
4. Pass necessary parameters like report, iouType, shouldSkipConfirmation, transaction details, and action-specific callbacks

The utility function would have a signature like:

  function handleExpenseNavigation(params: {
      report: OnyxEntry<Report>;
      iouType: ValueOf<typeof CONST.IOU.TYPE>;
      shouldSkipConfirmation: boolean;
      reportNameValuePairs?: OnyxEntry<ReportNameValuePairs>;
      personalDetails: OnyxEntry<PersonalDetailsList>;
      reportAttributesDerived?: ReportAttributesDerivedValue['reports'];
      navigationCallback?: () => void;
      expenseActionParams?: ExpenseActionParams;
  })

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

1. Test expense creation from report composer: Verify that starting an expense from the + button inside a report correctly auto-assigns participants and skips the
   participant selection step
2. Test expense creation from global create menu with Track option: Ensure participants are correctly extracted from the selected report
3. Test expense creation with Create option (combined flow): Verify users are redirected to the participants page when using the Create expense option
4. Test archived report handling: Ensure archived reports don't trigger the automatic participant assignment
5. Test each IOU type flow: Create tests for TRACK, SUBMIT, REQUEST, PAY, SEND, and SPLIT to ensure the correct action is called with proper parameters
6. Test shouldSkipConfirmation scenarios: Verify that when skipping confirmation, the appropriate immediate actions are taken for each IOU type
7. Test edge cases: Empty participants list, missing report data, and invalid IOU types should be handled gracefully

What alternative solutions did you explore? (Optional)

1. Custom React Hook: Create a useExpenseNavigation hook that encapsulates the logic. However, this would be less flexible as it couples the logic to React
   components and wouldn't be easily testable in isolation.
2. Higher-Order Component (HOC): Wrap the step components with an HOC that handles the navigation logic. This approach would add unnecessary complexity and reduce
   code readability.
3. Separate navigation handlers for each IOU type: Create individual functions for each IOU type (handleTrackExpense, handleSubmitExpense, etc.). While this
   provides better separation of concerns, it would still result in some duplication of the common logic like participant extraction and mapping.

[marufsharifi]

🚨 Edited by proposal-police: This proposal was edited at 2025-08-26 09:33:06 UTC.

Proposal

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

Clean up duplicated create expense navigation logic

What is the root cause of that problem?

The logic for handling existing reports (checking reportID, archiving status, and iouType), deriving participants from the report, and deciding whether to skip confirmation (leading to direct transaction creation or participant setting followed by navigation) is duplicated across multiple files and components. This duplication stems from inlining the entire flow in each context (e.g., scan, distance, amount) without abstraction, leading to repeated code that's hard to maintain. While the core structure is identical, each instance includes minor adjustments tailored to the specific IOU flow (e.g., handling files in scan flows, waypoints in distance flows, payment methods in amount flows), which has prevented straightforward reuse.

Where has it been used

App/src/pages/iou/request/step/IOURequestStepScan/index.tsx

Lines 444 to 456 in 8999bc7

	// If a reportID exists in the report object, it's because either:
	// - The user started this flow from using the + button in the composer inside a report.
	// - The user started this flow from using the global create menu by selecting the Track expense option.
	// In this case, the participants can be automatically assigned from the report and the user can skip the participants step and go straight
	// to the confirm step.
	// If the user is started this flow using the Create expense option (combined submit/track flow), they should be redirected to the participants page.
	if (report?.reportID && !isArchivedReport(reportNameValuePairs) && iouType !== CONST.IOU.TYPE.CREATE) {
	const selectedParticipants = getMoneyRequestParticipantsFromReport(report);
	const participants = selectedParticipants.map((participant) => {
	const participantAccountID = participant?.accountID ?? CONST.DEFAULT_NUMBER_ID;
	return participantAccountID ? getParticipantsOption(participant, personalDetails) : getReportOption(participant, reportAttributesDerived);
	});

App/src/pages/iou/request/step/IOURequestStepScan/index.native.tsx

Lines 387 to 398 in 22df923

	// If a reportID exists in the report object, it's because either:
	// - The user started this flow from using the + button in the composer inside a report.
	// - The user started this flow from using the global create menu by selecting the Track expense option.
	// In this case, the participants can be automatically assigned from the report and the user can skip the participants step and go straight
	// to the confirm step.
	// If the user is started this flow using the Create expense option (combined submit/track flow), they should be redirected to the participants page.
	if (report?.reportID && !isArchivedReport(reportNameValuePairs) && iouType !== CONST.IOU.TYPE.CREATE) {
	const selectedParticipants = getMoneyRequestParticipantsFromReport(report);
	const participants = selectedParticipants.map((participant) => {
	const participantAccountID = participant?.accountID ?? CONST.DEFAULT_NUMBER_ID;
	return participantAccountID ? getParticipantsOption(participant, personalDetails) : getReportOption(participant, reportAttributesDerived);
	});

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

Lines 302 to 317 in 22df923

	// If a reportID exists in the report object, it's because either:
	// - The user started this flow from using the + button in the composer inside a report.
	// - The user started this flow from using the global create menu by selecting the Track expense option.
	// In this case, the participants can be automatically assigned from the report and the user can skip the participants step and go straight
	// to the confirm step.
	// If the user started this flow using the Create expense option (combined submit/track flow), they should be redirected to the participants page.
	if (report?.reportID && !isArchivedReport(reportNameValuePairs) && iouType !== CONST.IOU.TYPE.CREATE) {
	const selectedParticipants = getMoneyRequestParticipantsFromReport(report);
	const participants = selectedParticipants.map((participant) => {
	const participantAccountID = participant?.accountID ?? CONST.DEFAULT_NUMBER_ID;
	return participantAccountID ? getParticipantsOption(participant, personalDetails) : getReportOption(participant, reportAttributesDerived);
	});
	setDistanceRequestData(participants);
	if (shouldSkipConfirmation) {
	setMoneyRequestPendingFields(transactionID, {waypoints: CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD});
	setMoneyRequestMerchant(transactionID, translate('iou.fieldPending'), false);

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

Lines 302 to 314 in 22df923

	// If a reportID exists in the report object, it's because either:
	// - The user started this flow from using the + button in the composer inside a report.
	// - The user started this flow from using the global create menu by selecting the Track expense option.
	// In this case, the participants can be automatically assigned from the report and the user can skip the participants step and go straight
	// to the confirm step.
	// If the user started this flow using the Create expense option (combined submit/track flow), they should be redirected to the participants page.
	if (report?.reportID && !isArchivedReport(reportNameValuePairs) && iouType !== CONST.IOU.TYPE.CREATE) {
	const selectedParticipants = getMoneyRequestParticipantsFromReport(report);
	const participants = selectedParticipants.map((participant) => {
	const participantAccountID = participant?.accountID ?? CONST.DEFAULT_NUMBER_ID;
	return participantAccountID ? getParticipantsOption(participant, personalDetails) : getReportOption(participant, reportAttributesDerived);
	});
	setDistanceRequestData(participants);

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

Lines 180 to 192 in 22df923

	// If a reportID exists in the report object, it's because either:
	// - The user started this flow from using the + button in the composer inside a report.
	// - The user started this flow from using the global create menu by selecting the Track expense option.
	// In this case, the participants can be automatically assigned from the report and the user can skip the participants step and go straight
	// to the confirm step.
	// If the user is started this flow using the Create expense option (combined submit/track flow), they should be redirected to the participants page.
	if (report?.reportID && !isArchivedReport(reportNameValuePairs) && iouType !== CONST.IOU.TYPE.CREATE) {
	const selectedParticipants = getMoneyRequestParticipantsFromReport(report);
	const participants = selectedParticipants.map((participant) => {
	const participantAccountID = participant?.accountID ?? CONST.DEFAULT_NUMBER_ID;
	return participantAccountID ? getParticipantsOption(participant, personalDetails) : getReportOption(participant, reportAttributesDerived);
	});
	const backendAmount = convertToBackendAmount(Number.parseFloat(amount));

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

To address this, we should extract the common logic into a shared utility function, e.g., handleReportBasedNavigation (placed in a logical location like src/libs/IOUUtils.ts or src/libs/ReportUtils.ts). This function will encapsulate the repeated checks and participant derivation, while allowing customization for flow-specific differences via parameters, callbacks, or optional props. This ensures consistency, reduces duplication, and makes it easier to update the logic in one place.

type HandleReportBasedNavigationParams = {
    report: Report;
    reportNameValuePairs: ReportNameValuePairs;
    iouType: IOUType;
    personalDetails: PersonalDetails;
    reportAttributesDerived: ReportAttributesDerived;
    currentUserPersonalDetails: CurrentUserPersonalDetails;
    shouldSkipConfirmation: boolean;
    policy: Policy;
    navigateToConfirmationPage: () => void;
    // Optional flow-specific params
    files?: File[];
    transactionID?: string;
    transactionIDs?: string[]; // For multi-file cases
    amount?: string;
    currency?: string;
    transaction?: Transaction;
    waypoints?: Waypoints;
    customUnitRateID?: string;
    lastSelectedDistanceRates?: LastSelectedDistanceRates;
    locationPermissionGranted?: boolean;
    paymentMethod?: PaymentMethod;
    isSplitBill?: boolean;
    backToReport?: () => void;
    shouldGenerateTransactionThreadReport?: boolean;
    // Callbacks for custom logic
    onParticipantsReady?: (participants: Participant[]) => void; // e.g., setDistanceRequestData
    skipConfirmationAction: (participants: Participant[], participant: Participant | undefined) => void; // Direct creation logic
    setParticipantsAction: () => Promise<void>; // Custom set participants (single/multi)
};

function handleReportBasedNavigation(params: HandleReportBasedNavigationParams) {
    if (!params.report?.reportID || isArchivedReport(params.reportNameValuePairs) || params.iouType === CONST.IOU.TYPE.CREATE) {
        return; // Early exit if conditions not met
    }

    const selectedParticipants = getMoneyRequestParticipantsFromReport(params.report);
    const participants = selectedParticipants.map((participant) => {
        const participantAccountID = participant?.accountID ?? CONST.DEFAULT_NUMBER_ID;
        return participantAccountID 
            ? getParticipantsOption(participant, params.personalDetails) 
            : getReportOption(participant, params.reportAttributesDerived);
    });

    if (params.onParticipantsReady) {
        params.onParticipantsReady(participants);
    }

    if (params.shouldSkipConfirmation) {
        const participant = participants.at(0);
        params.skipConfirmationAction(participants, participant);
        return;
    }

    // Handle set participants (custom per flow)
    await params.setParticipantsAction();
    params.navigateToConfirmationPage();
}

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

1. Common Logic Tests (All Flows):

   • Report exists, not archived, iouType not CREATE: Derives participants correctly and proceeds.
   • Report missing/archived/iouType CREATE: Early exits without actions.
   • Participant mapping: Handles both accountID-based and report-based options.

2. Scan Flow:

   • Skip confirmation true:
     • SPLIT with receipt: Calls startSplitBill with correct params.
     • Non-SPLIT with location granted: Calls getCurrentPosition and createTransaction with GPS.
     • Non-SPLIT without location or GPS error: Falls back to createTransaction without GPS.
     • Web vs Native param differences: Verify extra params (e.g., false, true) only in web.
   • Skip confirmation false:
     • Multi-files: Calls set participants (multiple or individual/Promise.all) and navigates.
   • Edge: No participants, no files.

3. **Distance **:

   • Skip confirmation true:
     • TRACK: Calls trackExpense with pending merchant, valid waypoints.
     • Non-TRACK: Calls createDistanceRequest with params like customUnitRateID.
   • Skip confirmation false: Single set participants and navigate.
   • Edge: Invalid waypoints, no customUnitRateID.

4. Amount Flow:

   • Skip confirmation true:
     • PAY/SEND: Calls sendMoneyWithWallet or sendMoneyElsewhere based on paymentMethod.
     • SUBMIT/REQUEST: Calls requestMoney with backend amount.
     • TRACK: Calls trackExpense.
   • Skip confirmation false: Optional setSplitShares if conditions met, then set participants and navigate.
   • Edge: Invalid amount, no currency.

5. General Edge Cases:

   • No participants resolved: Graceful handling (e.g., early return).
   • Malformed report or params: No crashes, logs errors where appropriate.
   • Platform-specific (web/native): Separate tests for param variations.

What alternative solutions did you explore? (Optional)

[rohit9625]

Hi @neil-marcellini, does this task only involve reducing only duplicated navigation logic or other related functions as well, that are repeated?