[Search v2.3] - Dropdown title does not follow search name, "type:expense" is shown in the list

[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.35-0
Reproducible in staging?: Y
Reproducible in production?: N/A - new feature, doesn't exist in prod
Issue was found when executing this PR: #48566
Email or phone of affected tester (no customers): applausetester+kh010901@applause.expensifail.com
Issue reported by: Applause Internal Team

Action Performed:

Precondition:

• User has saved a few searches.

1. Go to staging.new.expensify.com
2. Go to Search.
3. Tap on the dropdown.
4. Open any saved search.
5. Tap on the dropdown.

Expected Result:

In Step 4, the dropdown title should follow the name of the search.
In Step 5, when viewing a saved search, there should not be "type:expense" tab in the dropdown list.

Actual Result:

In Step 4, the dropdown title shows the name "type:expense".
In Step 5, when viewing a saved search, there is a "type:expense" tab in the dropdown list.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug6603107_1726282285065.ScreenRecording_09-14-2024_10-48-24_1.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @lakchote

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @danieldoglas (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[dominictb]

Proposal

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

• In Step 4, the dropdown title shows the name "type:expense".
• In Step 5, when viewing a saved search, there is a "type:expense" tab in the dropdown list.

What is the root cause of that problem?

• If the saved search have custom name, we don't display it
  

  App/src/pages/Search/SearchTypeMenu.tsx

  Line 78 in 587698f

  const title = isCannedQuery ? undefined : SearchUtils.getSearchHeaderTitle(queryJSON, personalDetails, cardList, reports, taxRates);

  
  but we display its query json instead.

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

• When user click on any saved search, we need to add its custom name to the url, such as &name=.... Based on it, we can display the dropdown title.

• First, we need to update:
  

  App/src/pages/Search/SearchTypeMenu.tsx

  Line 110 in 0c618ac

  Navigation.navigate(ROUTES.SEARCH_CENTRAL_PANE.getRoute({query: item?.query ?? ''}));

                    Navigation.navigate(ROUTES.SEARCH_CENTRAL_PANE.getRoute({query: item?.query ?? '', name: item.name}));

• And modify the ROUTES:

App/src/ROUTES.ts

Line 38 in 0c618ac

getRoute: ({query}: {query: SearchQueryString}) => `search?q=${encodeURIComponent(query)}` as const,

        getRoute: ({query, name}: {query: SearchQueryString; name: string}) => `search?q=${encodeURIComponent(query)}${name ? `&name=${name}` : ''}` as const,

• Finally, update:

App/src/pages/Search/SearchTypeMenu.tsx

Line 186 in 0c618ac

const title = isCannedQuery ? undefined : SearchUtils.getSearchHeaderTitle(queryJSON, personalDetails, cardList, reports, taxRates);

        const title = searchName ?? (isCannedQuery ? undefined : SearchUtils.getSearchHeaderTitle(queryJSON, personalDetails, cardList, reports, taxRates));

with the searchName comes from url.

What alternative solutions did you explore? (Optional)

[luacmartins]

This is known and will be addressed in a follow up.

[lakchote]

@dominictb are you available to implement the fix?

[dominictb]

I can work on it

[lakchote]

I can work on it

If you could raise the PR today that'd be great.

[dominictb]

@lakchote PR is ready.

[brunovjk]

👋 @lakchote I have reviewed the PR, can you please assign me here so I can complete the BugZero Checklist? Thank you.

• The PR went into production on Sep 30.

[brunovjk]

• [@brunovjk] The PR that introduced the bug has been identified. Link to the PR: [Search v2.3] [App] Implement Saved Search feature #48566
• [@brunovjk] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment: I don't believe it can be considered a regression, but rather a polishing, already pointed out in the PR here.
• [@brunovjk] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
• [@brunovjk] Determine if we should create a regression test for this bug. Yes
• [@brunovjk] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.

Regression Test Proposal

Precondition: Small screen device. User has saved a few searches.

1. Test case 1:

• Go to Search.
• Tap on the dropdown.
• Open any saved search. Verify the dropdown title should follow the name of the search.

2. Test case 2:

• Go to Search.
• Tap on the dropdown.
• Click three dots on any option > Rename > Enter a new name > Save.
• Verify the dropdown title should follow the new name.

3. Test case 3:

• Go to Search.
• Tap on the dropdown.
• Verify we dont see the custom menu item, if we're viewing a saved search.

Do we agree 👍 or 👎?