[HOLD for payment 2024-10-22] [$250] Book travel - Report screen changes to profile view when clicking Country field

[IuliiaHerets]

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.0.44-0
Reproducible in staging?: Y
Reproducible in production?: Y
Email or phone of affected tester (no customers): applausetester+kh0110001@applause.expensifail.com
Issue reported by: Applause Internal Team

Action Performed:

1. Go to staging.new.expensify.com
2. Go to FAB > Book travel.
3. Click Book travel.
4. Click Country.

Expected Result:

The report screen in the background will not change to profile page.

Actual Result:

The report screen in the background changes to profile page while LHN remains the same after opening Country RHP.

Workaround:

Unknown

Platforms:

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Bug6623236_1727962477743.20241003_211113.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021843246313566765560
• Upwork Job ID: 1843246313566765560
• Last Price Increase: 2024-10-07
• Automatic offers:
• dukenv0307 | Contributor | 104317443

Issue Owner

Current Issue Owner: @trjExpensify

[melvin-bot]

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

[IuliiaHerets]

We think that this bug might be related to #vip-travel

[IuliiaHerets]

@trjExpensify FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors

[bernhardoj]

Proposal

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

Report screen changes to profile screen when open the Country page from the book travel page.

What is the root cause of that problem?

By default, the address country RHP maps to the profile screen.

App/src/libs/Navigation/linkingConfig/CENTRAL_PANE_TO_RHP_MAPPING.ts

Lines 5 to 21 in 91f610c

	[SCREENS.SETTINGS.PROFILE.ROOT]: [
	SCREENS.SETTINGS.PROFILE.DISPLAY_NAME,
	SCREENS.SETTINGS.PROFILE.CONTACT_METHODS,
	SCREENS.SETTINGS.PROFILE.CONTACT_METHOD_DETAILS,
	SCREENS.SETTINGS.PROFILE.CONTACT_METHOD_VALIDATE_ACTION,
	SCREENS.SETTINGS.PROFILE.NEW_CONTACT_METHOD,
	SCREENS.SETTINGS.PROFILE.STATUS_CLEAR_AFTER,
	SCREENS.SETTINGS.PROFILE.STATUS_CLEAR_AFTER_DATE,
	SCREENS.SETTINGS.PROFILE.STATUS_CLEAR_AFTER_TIME,
	SCREENS.SETTINGS.PROFILE.STATUS,
	SCREENS.SETTINGS.PROFILE.PRONOUNS,
	SCREENS.SETTINGS.PROFILE.TIMEZONE,
	SCREENS.SETTINGS.PROFILE.TIMEZONE_SELECT,
	SCREENS.SETTINGS.PROFILE.LEGAL_NAME,
	SCREENS.SETTINGS.PROFILE.DATE_OF_BIRTH,
	SCREENS.SETTINGS.PROFILE.ADDRESS,
	SCREENS.SETTINGS.PROFILE.ADDRESS_COUNTRY,

But we have a logic to find the matching central pane screen based on the backTo params.

App/src/libs/Navigation/linkingConfig/getAdaptedStateFromPath.ts

Lines 114 to 139 in 91f610c

	if (route.params && 'backTo' in route.params && typeof route.params.backTo === 'string') {
	const stateForBackTo = getStateFromPath(route.params.backTo, config);
	if (stateForBackTo) {
	// If there is rhpNavigator in the state generated for backTo url, we want to get root route matching to this rhp screen.
	const rhpNavigator = stateForBackTo.routes.find((rt) => rt.name === NAVIGATORS.RIGHT_MODAL_NAVIGATOR);
	if (rhpNavigator && rhpNavigator.state) {
	const isRHPinState = stateForBackTo.routes.at(0)?.name === NAVIGATORS.RIGHT_MODAL_NAVIGATOR;
	if (isRHPinState) {
	return getMatchingRootRouteForRHPRoute(findFocusedRoute(stateForBackTo) as NavigationPartialRoute);
	}
	}
	// If we know that backTo targets the root route (full screen) we want to use it.
	const fullScreenNavigator = stateForBackTo.routes.find((rt) => rt.name === NAVIGATORS.FULL_SCREEN_NAVIGATOR);
	if (fullScreenNavigator && fullScreenNavigator.state) {
	return fullScreenNavigator as NavigationPartialRoute<CentralPaneName | typeof NAVIGATORS.FULL_SCREEN_NAVIGATOR>;
	}
	// If we know that backTo targets a central pane screen we want to use it.
	const centralPaneScreen = stateForBackTo.routes.find((rt) => isCentralPaneName(rt.name));
	if (centralPaneScreen) {
	return centralPaneScreen as NavigationPartialRoute<CentralPaneName | typeof NAVIGATORS.FULL_SCREEN_NAVIGATOR>;
	}
	}
	}

In our case, the last backTo param is the travel page which doesn't have a central pane screen mapping, which will later be defaulted to the report screen.

App/src/libs/Navigation/linkingConfig/getAdaptedStateFromPath.ts

Line 203 in 91f610c

matchingRootRoute = matchingRootRoute ?? (!isNarrowLayout ? {name: SCREENS.REPORT} : undefined);

However, the result is ignored because of isRHPinState is false here.

App/src/libs/Navigation/linkingConfig/getAdaptedStateFromPath.ts

Lines 119 to 125 in 91f610c

	if (rhpNavigator && rhpNavigator.state) {
	const isRHPinState = stateForBackTo.routes.at(0)?.name === NAVIGATORS.RIGHT_MODAL_NAVIGATOR;
	if (isRHPinState) {
	return getMatchingRootRouteForRHPRoute(findFocusedRoute(stateForBackTo) as NavigationPartialRoute);
	}
	}

It's because stateForBackTo.routes contains [BottomTabNavigator, RHPNavigator], so always accessing the first index won't work. We can just remove isRHPinState because we already have rhpNavigator which already finds RHP inside stateForBackTo.routes.

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

Remove the isRHPInState. We previously fixed this before, but the isRHPinState is reintroduced in #49534, specifically this changes. I believe it's a bad merge.

[trjExpensify]

Filing this one under vip-travel. CC: @stitesExpensify