[Due for payment 2025-07-01] [$250] Per Diem - Back button from "Edit Per diem rates" page navigates to the WS list

[nlemma]

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.59-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail: #63303
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Device used: Windows 10 / Chrome, macOS Sequoia 15.5
App Component: Workspace Settings

Action Performed:

1. Navigate to https://staging.new.expensify.com/
2. Log in with any account
3. Create a workspace
4. Navigate to Workspace settings - More features
5. Enable "Per diem"
6. Navigate to the workspace chat
7. Navigate to "+" - Create expense - Per diem
8. Click on the "Edit per diem rates" button
9. Click on the "<" button

Expected Result:

Expense creation page should open.

Actual Result:

Back button from "Edit Per diem rates" page navigates to the WS list.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug6850867_1749065870773.bandicam_2025-06-04_21-29-37-161.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021932516167347133365
• Upwork Job ID: 1932516167347133365
• Last Price Increase: 2025-06-10
• Automatic offers:
• linhvovan29546 | Contributor | 107697060

Issue Owner

Current Issue Owner: @isabelastisser

[melvin-bot]

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

[linhvovan29546]

🚨 Edited by proposal-police: This proposal was edited at 2025-06-11 00:58:21 UTC.

Proposal

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

Per Diem - Back button from "Edit Per diem rates" page navigates to the WS list

What is the root cause of that problem?

When navigating to the Edit Per Diem Rate screen from the Create Expense flow, we pass the backTo route via:

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

Lines 146 to 148 in e1766ef

	InteractionManager.runAfterInteractions(() => {
	Navigation.navigate(ROUTES.WORKSPACE_PER_DIEM.getRoute(policy.id, Navigation.getActiveRoute()));
	});

This means that when pressing the Back button on the Edit Per Diem Rate screen, we expect it to return to the Create Expense page.

However, on desktop (wide layout), when we click Back button("<") from the WorkspaceInitialPage (which is split-screen layout), and the route not include the backTo param it only contains the policyID. This causes the fallback to default to WORKSPACES_LIST, which is incorrect.

App/src/pages/workspace/WorkspaceInitialPage.tsx

Line 453 in e1766ef

onBackButtonPress={() => Navigation.goBack(route.params?.backTo ?? ROUTES.WORKSPACES_LIST.route)}

The reason backTo is missing in the WorkspaceInitialPage is that we navigate directly to the perdiem page. In this flow, getParamsFromRoute is used to extract parameters matching the regex and then pass them to the initial page. However, the backTo parameter is not included in this process (since backTo is not part of the workspace initial path), which causes it to be missing.

App/src/libs/Navigation/AppNavigator/createSplitNavigator/SplitRouter.ts

Lines 62 to 63 in 1cd33a2

	const paramsFromRoute = getParamsFromRoute(sidebarScreen);
	const copiedParams = pick(lastRoute?.params, paramsFromRoute);

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

We should use findFocusedRoute and useNavigationState to access the route parameters from the focused route instead of relying on route.params from the split-screen parent and use as fallback value of route.params.

App/src/pages/workspace/WorkspaceInitialPage.tsx

Line 453 in e1766ef

onBackButtonPress={() => Navigation.goBack(route.params?.backTo ?? ROUTES.WORKSPACES_LIST.route)}

    const activeRouteParams = useNavigationState((state) => findFocusedRoute(state)?.params); //We can improve this by using the existing useNavigationState during the PR phase
....
                <HeaderWithBackButton
                    title={policyName}
                    onBackButtonPress={() => Navigation.goBack(route.params?.backTo ?? activeRouteParams.backTo?? ROUTES.WORKSPACES_LIST.route)}
                    policyAvatar={policyAvatar}
                    shouldDisplayHelpButton={shouldUseNarrowLayout}
                />

I looked through various parts of the app and found that we actually use this pattern to get some params and names. So we're applying the same solution here to fix the issue.

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

We can write a unit test for this by rendering two screens, then asserting that goBack is called with the correct backTo parameter.

What alternative solutions did you explore? (Optional)

We can handle copying backTo from the central screen to the SidebarScreen.

App/src/libs/Navigation/AppNavigator/createSplitNavigator/SplitRouter.ts

Lines 61 to 63 in 1cd33a2

	if (!isAtLeastOneInState(state, sidebarScreen) && shouldSplitHaveSidebar) {
	const paramsFromRoute = getParamsFromRoute(sidebarScreen);
	const copiedParams = pick(lastRoute?.params, paramsFromRoute);

        let paramsFromRoute = getParamsFromRoute(sidebarScreen);
        if(sidebarScreen === SCREENS.WORKSPACE.INITIAL){ // We can test this to see if the issue occurs on other initial screen
        paramsFromRoute=[...paramsFromRoute,'backTo'];
        }

Alternatively, we can move the above logic into getParamsFromRoute as shown below, and then pass true as the second parameter.

const SHARED_PARAMS_CONFIG: Partial<Record<Screen, string[]>> = {
    [SCREENS.WORKSPACE.INITIAL]: ['backTo'],
};
function getParamsFromRoute(screenName: string,shouldUseShareParams?:boolean): string[] {
    const routeConfig = normalizedConfigs[screenName as Screen];

    const route = routeConfig.pattern;

    // Extract path parameters (like :policyID) from the route pattern
    const pathParams = route.match(/(?<=[:?&])(\w+)(?=[/=?&]|$)/g) ?? [];
    
    // Get shared parameters from the configuration
    const sharedParams = shouldUseShareParams ? SHARED_PARAMS_CONFIG[screenName as Screen] ?? []:[];
    
    // Combine both path parameters and shared parameters
    return [...pathParams, ...sharedParams];
}

[melvin-bot]

@isabelastisser Eep! 4 days overdue now. Issues have feelings too...

[melvin-bot]

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

[melvin-bot]

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

[isabelastisser]

Hi @akinwale, can you please review the proposal above? Thanks!