[HOLD for payment 2024-09-06][Search v2.1] Keep user on Search page if expense is created from Search page

[shawnborton]

Problem

If you are on the Search page and you create an expense, you get taken back to the Inbox page. This is jarring because the user would actually expect to remain on the Search page and see the expense show up in the Search table.

Solution

Let's make it so that if you were on the Search page and you create an expense, you land back on the Search page. We could make it so that you just return to the Search table and see the table populate with the new expense, or we could open up the report or workspace chat in the RHP.

Note: right now we have the ability to open up a report or expense in the RHP on Search but I don't think we can open up a workspace chat in the RHP on the Search page?

cc @Expensify/design @trjExpensify @JmillsExpensify @luacmartins

@trjExpensify - can you file this one where you want it?

Issue Owner

Current Issue Owner: @trjExpensify

[luacmartins]

This is related to #41020, since the nav refactor would have to handle both the RHP and main pane navs

[trjExpensify]

Should we put this in #wave-control then with everything else Search related?

Let's make it so that if you were on the Search page and you create an expense, you land back on the Search page. We could make it so that you just return to the Search table and see the table populate with the new expense, or we could open up the report or workspace chat in the RHP.

Maybe the v1 pre-refactor is landing back on the table with the new expense row created highlighted for emphasis or something?

[shawnborton]

I could totally get down with that as a v1.

[dannymcclain]

Same, I think that'd be nice as a v1.

[luacmartins]

@adamgrzybowski @WojtekBoman since you're more familiar with navigation logic, how involved do you think it'd be to implement this?

[JmillsExpensify]

Zooming out a bit, given the navigation refactors required for this issue, I think I'd still choose prioritizing Search 2.3 and 2.4 ahead of this initiative. Still down to see how "big" of an effort it is regardless though.

[adamgrzybowski]

@luacmartins I did some quick research and we call the dismissModal function with the reportID argument on confirm.

If we call this without argument, the user should stay on the search page.

We can conditionally remove the argument if the topmost central pane is the search page.

[luacmartins]

That sounds good. If it's an easy fix, let's go for it.