[$250] User lands on concierge instead of the LHN

[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.0.60-1
Reproducible in staging?: y
Reproducible in production?: y
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?:
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: @shawnborton
Slack conversation (hyperlinked to channel name): [expensify_convert] (https://expensify-ts.slack.com/archives/C07HPDRELLD/p1731430243357459)

Action Performed:

1. Sign up for new account in mobile device
2. Complete onboarding

Expected Result:

User lands in LHN

Actual Result:

User lands in Concierge

Workaround:

unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android: Standalone
• Android: HybridApp
• Android: mWeb Chrome
• iOS: Standalone
• iOS: HybridApp
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021857485391551648841
• Upwork Job ID: 1857485391551648841
• Last Price Increase: 2024-11-22

Issue Owner

Current Issue Owner: @mkzie2

[melvin-bot]

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

[Nodebrute]

Proposal

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

User lands on concierge instead of the LHN

What is the root cause of that problem?

from here we get lastAccessedReport

App/src/libs/navigateAfterOnboarding.ts

Line 24 in dc1e79d

const lastAccessedReport = ReportUtils.findLastAccessedReport(!canUseDefaultRooms, shouldOpenOnAdminRoom(), activeWorkspaceID);

and then in here, we navigate to it

App/src/libs/navigateAfterOnboarding.ts

Line 37 in dc1e79d

Navigation.navigate(lastAccessedReportRoute);

The problem is the findLastAccessedReport function will return the concierge report as the last accessed report.

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

To exclude it, we can pass conciergeChatReportID as the fourth parameter here, ensuring we always navigate to the LHN, except in cases where the public room was opened first.

App/src/libs/navigateAfterOnboarding.ts

Line 24 in dc1e79d

const lastAccessedReport = ReportUtils.findLastAccessedReport(!canUseDefaultRooms, shouldOpenOnAdminRoom(), activeWorkspaceID);

We can retrieve the concierge ID either by passing it as a prop or by implementing something like this

let conciergeChatReportID: string | undefined;
Onyx.connect({
    key: ONYXKEYS.CONCIERGE_REPORT_ID,
    callback: (value) => (conciergeChatReportID = value),
});

What alternative solutions did you explore? (Optional)

[Shahidullah-Muffakir]

Based on this issue, #52018
there seems to be an inconsistency regarding the expected behavior of where a user should land after completing onboarding

[melvin-bot]

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

[melvin-bot]

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

[MitchExpensify]

The expected bahevior is to land in LHN

[mkzie2]

Edited by proposal-police: This proposal was edited at 2024-11-26 09:13:08 UTC.

Proposal

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

In Step 5, user is redirected to LHN after completing onboarding when "Manage my team's expenses" is selected.

What is the root cause of that problem?

If we select Manage team's expenses, a WS and a WS chat are created

App/src/pages/OnboardingAccounting/BaseOnboardingAccounting.tsx

Line 154 in 6778419

navigateAfterOnboarding(isSmallScreenWidth, shouldUseNarrowLayout, canUseDefaultRooms, onboardingPolicyID, activeWorkspaceID, route.params?.backTo);

Then lastAccessedReport is the WS chat of the onboarding policy. In the small screen, shouldUseNarrowLayout is true so the user lands on LHN

App/src/libs/navigateAfterOnboarding.ts

Lines 27 to 35 in 6778419

	if (!lastAccessedReportID || lastAccessedReport.policyID === onboardingPolicyID) {
	// Only navigate to concierge chat when central pane is visible
	// Otherwise stay on the chats screen.
	if (!shouldUseNarrowLayout && !backTo) {
	Report.navigateToConciergeChat();
	}
	return;
	}

If we select another purpose, the lastAccessedReport is the concierge chat so the user lands in the concierge chat

App/src/libs/navigateAfterOnboarding.ts

Line 37 in 6778419

Navigation.navigate(lastAccessedReportRoute);

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

We should return early here if the lastAccessedReport is the concierge. So this will only move to the lastAccessedReport in case we sign in with a public room.

if (ReportUtils.isConciergeChatReport(lastAccessedReport)) {
    return;
}

App/src/libs/navigateAfterOnboarding.ts

Line 36 in 664f826

const lastAccessedReportRoute = ROUTES.REPORT_WITH_ID.getRoute(lastAccessedReportID ?? '-1');

Optional: Another thing, we already return early if isSmallScreenWidth is false here

App/src/libs/navigateAfterOnboarding.ts

Line 20 in 664f826

if (!isSmallScreenWidth) {

And if isSmallScreenWidth is true, shouldUseNarrowLayout is always true and this condition is always false so we can remove this block.

App/src/libs/navigateAfterOnboarding.ts

Lines 30 to 32 in 664f826

	if (!shouldUseNarrowLayout && !backTo) {
	Report.navigateToConciergeChat();
	}

If we want to do that we can merge ReportUtils.isConciergeChatReport(lastAccessedReport) to this line. After all, we can have a cleaner function like this

Navigation.dismissModal();

// When hasCompletedGuidedSetupFlow is true, OnboardingModalNavigator in AuthScreen is removed from the navigation stack.
// On small screens, this removal redirects navigation to HOME. Dismissing the modal doesn't work properly,
// so we need to specifically navigate to the last accessed report.
if (!isSmallScreenWidth) {
    return;
}

const lastAccessedReport = ReportUtils.findLastAccessedReport(!canUseDefaultRooms, shouldOpenOnAdminRoom(), activeWorkspaceID);
const lastAccessedReportID = lastAccessedReport?.reportID;
// we don't want to navigate to newly creaded workspace after onboarding completed.
if (!lastAccessedReportID || lastAccessedReport.policyID === onboardingPolicyID || ReportUtils.isConciergeChatReport(lastAccessedReport)) {
    return;
}

const lastAccessedReportRoute = ROUTES.REPORT_WITH_ID.getRoute(lastAccessedReportID ?? '-1');
Navigation.navigate(lastAccessedReportRoute);

What alternative solutions did you explore? (Optional)

[mkzie2]

I created a proposal in this issue #52018 and bring it here since it's the same issue.

[danielrvidal]

@mollfpr any thoughts on which proposal to go with?

[mollfpr]

The expected bahevior is to land in LHN

@MitchExpensify @danielrvidal For clarification could you list the expected in the below purposes whether LHN or Concierge?

1. Track and budget expense:
2. Manage my team's expense:
3. Get paid back by my employer:
4. Chat and split expenses with friends:
5. Something else:

[MitchExpensify]

Its the same (LHN) for all, right @danielrvidal ?

[mkzie2]

I think we should navigate to the concierge chat for all cases because we can have some tasks created in the concierge chat from the onboarding flow. Then the user can see the task after the onboarding flow if we navigate to the concierge chat.

cc @danielrvidal

[mollfpr]

I think we should navigate to the concierge chat for all cases because we can have some tasks created in the concierge chat from the onboarding flow.

@mkzie2 Interesting, but the flow for "Something else" doesn't create tasks in the concierge, why do we need to navigate to the concierge in that case?

[mkzie2]

@mollfpr We want to be consistent for all onboarding flow so I suggest navigating to the concierge chat with the reason above.

[Nodebrute]

The expected bahevior is to land in LHN

@mollfpr The expected result is that the user should land on the LHN. The previous issue (#52018) was closed because the expected result provided at the time was incorrect.

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[danielrvidal]

Yea, we want them to land on the inbox in the LHN rather than in the concierge DM because it's the home screen. We have a tooltip and GBR that direct them to go to the Concierge chat next.

[Shahidullah-Muffakir]

Edited by proposal-police: This proposal was edited at 2024-11-24 18:13:44 UTC.

Proposal

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

After the onboarding flow , user lands on the Concierge chat, instead of inbox or home page.

What is the root cause of that problem?

here:

App/src/libs/navigateAfterOnboarding.ts

Line 37 in 6778419

Navigation.navigate(lastAccessedReportRoute);

we are navigating to the last accessed report.

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

based on:
#52420 (comment) and #52420 (comment)

it seems, here:

App/src/libs/navigateAfterOnboarding.ts

Line 37 in 6778419

Navigation.navigate(lastAccessedReportRoute);

we can simply write:
Navigation.navigate(ROUTES.HOME);

What alternative solutions did you explore? (Optional)

I think we can totally replace these two lines:

App/src/pages/OnboardingAccounting/BaseOnboardingAccounting.tsx

Line 172 in f4f8da7

navigateAfterOnboarding(isSmallScreenWidth, shouldUseNarrowLayout, canUseDefaultRooms, onboardingPolicyID, activeWorkspaceID, route.params?.backTo);

and

App/src/pages/OnboardingPersonalDetails/BaseOnboardingPersonalDetails.tsx

Line 75 in f4f8da7

navigateAfterOnboarding(isSmallScreenWidth, shouldUseNarrowLayout, canUseDefaultRooms, onboardingPolicyID, activeWorkspaceID, route.params?.backTo);

with

   Navigation.dismissModal();
    Navigation.navigate(ROUTES.HOME);

[MitchExpensify]

What do you think about the latest proposal @mollfpr ?

[melvin-bot]

@mollfpr @MitchExpensify this issue was created 2 weeks ago. Are we close to approving a proposal? If not, what's blocking us from getting this issue assigned? Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

[mkzie2]

Updated proposal.

[melvin-bot]

@mollfpr, @MitchExpensify Huh... This is 4 days overdue. Who can take care of this?

[mollfpr]

Thank you guys for the proposals!

we are navigating to the last accessed report.

@Shahidullah-Muffakir Your RCA doesn't have much explanation, and your solution will not work with sign in from deeplink.

---

So to conclude, the solution from @Nodebrute and @mkzie2 has the same which to avoid navigating to the concierge chat report. The solution from @Nodebrute needs access to Onyx to get the concierge reportID so it needs more lines of code to define the Onyx value and add more parameters to the function, but the @mkzie2 solution only needs to check whether the lastAccessedReport is concierge chat and return early. So I suggest we go with @mkzie2 solution because the changes is straight forward.

🎀 👀 🎀 C+ reviewed!

[melvin-bot]

Triggered auto assignment to @MariaHCD, see https://stackoverflow.com/c/expensify/questions/7972 for more details.

[melvin-bot]

❌ There was an error making the offer to @mkzie2 for the Contributor role. The BZ member will need to manually hire the contributor.

[MitchExpensify]

@mkzie2 what is your Upwork profile?

[mkzie2]

@MitchExpensify It's https://www.upwork.com/freelancers/~019f73367b03c6d784

[MitchExpensify]

Thanks, offer sent @mkzie2 !

[mkzie2]

@mollfpr The PR is ready.

[MariaHCD]

@mkzie2 we had to revert your PR since it was causing typecheck and ESLint errors:

#54194
#54193

Please review the errors and resubmit a new PR. Thanks!

[mkzie2]

@MariaHCD I created a fix here for the error.

[mollfpr]

@MariaHCD @mkzie2 I think we still have time with the fix.

[mkzie2]

@mollfpr The PR is ready.