[Due for payment 2025-05-22] [Due for payment 2025-05-20] Tags - Introduction sentence is below the search field, instead of above the search field

[jponikarchuk]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Version Number: 9.1.42-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from TestRail: Exp
Email or phone of affected tester (no customers): [email protected]
Issue reported by: Applause Internal Team
Device used: iPhone 15 Pro Max / iOS 18.4
App Component: Workspace Settings

Action Performed:

Precondition:

• Workspace has at least 16 categories and 16 tags.

1. Launch Expensify app.
2. Go to workspace settings > Categories.
3. Note that the introduction sentence is above the search field.
4. Go to workspace settings > Tags.

Expected Result:

In Tags page, the introduction sentence should be above the search field.

Actual Result:

In Tags page, the introduction sentence is below the search field, which is not consistent with the placement in Categories page.

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

1.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @adelekennedy

[melvin-bot]

Triggered auto assignment to @adelekennedy (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 @srikarparsi (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[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.

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[olivierhabi]

Proposal

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

On the "Workspace Settings > Tags" page, the introductory sentence (e.g., "Tags add more detailed ways to classify costs.") appears below the "Find tag" search field. This is inconsistent with the "Workspace Settings > Categories" page, where a similar introductory sentence appears above its search field. We need to make the Tags page consistent by placing its introductory sentence above the search field.

What is the root cause of that problem?

The root cause is the conditional rendering logic and component structure, particularly for narrow (mobile) layouts.

When the Tags page has data to display on a narrow screen:

1. The SearchBar component was rendered directly in the page's main body.
2. The introductory text, generated by getHeaderText(), was then rendered inside the SelectionListWithModal component via its listHeaderContent prop.

This resulted in the SearchBar appearing visually before the introductory text because the text was part of a child component rendered later. On wide screens, or when the narrow screen was loading or showing an empty state, the introductory text was rendered in the main body, which was correct, but the "narrow screen with data" case was handled differently, leading to the inconsistency.

App/src/pages/workspace/tags/WorkspaceTagsPage.tsx

Lines 487 to 495 in 819bf62

	{(!shouldUseNarrowLayout || !hasVisibleTags || isLoading) && getHeaderText()}
	{tagList.length > CONST.SEARCH_ITEM_LIMIT && (
	<SearchBar
	label={translate('workspace.tags.findTag')}
	inputValue={inputValue}
	onChangeText={setInputValue}
	shouldShowEmptyState={hasVisibleTags && !isLoading && !filteredTagList.length}
	/>
	)}

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

We should adjust the rendering order in the WorkspaceTagsPage component to ensure the introductory text consistently appears before the search bar when appropriate.

1. Consolidate Rendering Logic: The introductory text (from getHeaderText()) and the SearchBar should both be rendered directly within the main component structure, outside of the SelectionListWithModal.
2. Conditional Visibility: This entire section (introductory text + search bar) should only be visible if the page is not in the narrow-screen multi-select mode (i.e., when selectionModeHeader is false).
3. Order of Elements:
   • First, render the introductory text using getHeaderText(). This function already wraps its content in a <View> with appropriate styling.
   • Second, conditionally render the SearchBar. The SearchBar should only appear if there are tags to search, the data is not loading, and the list of tags is long enough to warrant a search. It should be wrapped in a <View> with horizontal padding consistent with the introductory text and appropriate vertical spacing.
4. Remove from List Header: The listHeaderContent prop of the SelectionListWithModal component should no longer be used to render the introductory text. It can be set to null or used for other list-specific header content if needed in the future.

 {getHeaderText()}
    {!isLoading && hasVisibleTags && tagList.length > CONST.SEARCH_ITEM_LIMIT && (
        <SearchBar
          label={translate('workspace.tags.findTag')}
          inputValue={inputValue}
          onChangeText={setInputValue}
          shouldShowEmptyState={!filteredTagList.length}
      />
  )}

{hasVisibleTags && !isLoading && (
      <SelectionListWithModal
          canSelectMultiple={canSelectMultiple}
          turnOnSelectionModeOnLongPress={!isMultiLevelTags}
          onTurnOnSelectionMode={(item) => item && toggleTag(item)}
          sections={[{data: filteredTagList, isDisabled: false}]}
          onCheckboxPress={toggleTag}
          onSelectRow={navigateToTagSettings}
          shouldSingleExecuteRowSelect={!canSelectMultiple}
          onSelectAll={toggleAllTags}
          ListItem={TableListItem}
          customListHeader={getCustomListHeader()}
          shouldPreventDefaultFocusOnSelectRow={!canUseTouchScreen()}
          listHeaderWrapperStyle={[styles.ph9, styles.pv3, styles.pb5]}
          onDismissError={(item) => !isMultiLevelTags && clearPolicyTagErrors(policyID, item.value, 0)}
          listHeaderContent={null}
          showScrollIndicator={false}
          addBottomSafeAreaPadding
      />
 )}

This approach ensures that if the introductory text and search bar are meant to be shown, they are always rendered in the correct order (text above search) in the main page flow.

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

We should add or update tests to verify the layout of the introductory text and search bar on the Tags page under various conditions:

None

What alternative solutions did you explore? (Optional)

None

Result

Screen.Recording.2025-05-08.at.16.41.12.mov

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[adelekennedy]

I think we should update this but this is not a deploy blocker IMO - @srikarparsi if you disagree, going to drop the priority

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.1.44-8 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• fix: add search bar followups #61686

If no regressions arise, payment will be issued on 2025-05-20. 🎊

[melvin-bot]

@srikarparsi @adelekennedy @srikarparsi The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.1.45-21 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• fix: add search bar followups #61686

If no regressions arise, payment will be issued on 2025-05-22. 🎊

[melvin-bot]

@srikarparsi @adelekennedy @srikarparsi The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]