[$250] [Search v2.2] - Report name is bold when report is unread or select, and unbold when not unselected

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

Action Performed:

1. Go to staging.new.expensify.com
2. Go to Search > Chats.
3. Click Filters.
4. Click In.
5. Select some reports.

Expected Result:

There should be consistency whether the report name should be bold.

Actual Result:

The report name is bold when the report is unread or selected, and unbold when not selected.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug6601202_1726156396378.bandicam_2024-09-12_23-50-21-440.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021834272973003292308
• Upwork Job ID: 1834272973003292308
• Last Price Increase: 2024-09-12

Issue Owner

Current Issue Owner: @ikevin127

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

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

[Nodebrute]

@carlosmiceli Could you please confirm the expected behavior here?

[luacmartins]

I can take this one since it's part of Search. cc @Kicu @289Adam289

[dominictb]

Edited by proposal-police: This proposal was edited at 2024-09-12 18:01:30 UTC.

Proposal

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

The report name is bold when the report is unread or selected, and unbold when not selected.

What is the root cause of that problem?

• In the function to get the selected option, isBold value is always undefined:
  

  App/src/components/Search/SearchFiltersChatsSelector.tsx

  Lines 32 to 34 in 7748eff

  	function getSelectedOptionData(option: Option): OptionData {
  	return {...option, isSelected: true, reportID: option.reportID ?? '-1'};
  	}

so the option title is always bold because of:

App/src/components/SelectionList/InviteMemberListItem.tsx

Line 101 in 7748eff

item.isBold !== false && styles.sidebarLinkTextBold,

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

• We should update:
  

  App/src/components/Search/SearchFiltersChatsSelector.tsx

  Line 33 in 7748eff

  return {...option, isSelected: true, reportID: option.reportID ?? '-1'};

    return {...option, isSelected: true, reportID: option.reportID ?? '-1', isBold: OptionsListUtils.shouldUseBoldText(option)};

What alternative solutions did you explore? (Optional)

Solution 1:

• We also can update it:

        result.isBold = shouldUseBoldText(result);

Solution 2:

• In case we don't want to display bold style in this filter page, just need to introduce a new prop shouldUseBoldStyle in InviteMemberListItem component with the default value is true and update:
  

  App/src/components/SelectionList/InviteMemberListItem.tsx

  Line 101 in 7748eff

  item.isBold !== false && styles.sidebarLinkTextBold,

  
  to:

                                   shouldUseBoldStyle && item.isBold !== false && styles.sidebarLinkTextBold,

• Then, pass shouldUseBoldStyle={false} in:
  

  App/src/components/Search/SearchFiltersChatsSelector.tsx

  Line 166 in 7748eff

  <SelectionList

[dominictb]

Proposal updated

[ikevin127]

@luacmartins Are we accepting proposals for this one or will somebody from agencies work on it ?

[luacmartins]

Sure, we can take contributors too

[bernhardoj]

Proposal

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

The title bold is inconsistent in chat search filter In list.

What is the root cause of that problem?

In In chat filters, we use getSearchOptions which has shouldBoldTitleByDefault as false.

App/src/libs/OptionsListUtils.ts

Line 2067 in 1641532

shouldBoldTitleByDefault: false,

So, the title will be bold based on the unread status.

App/src/libs/OptionsListUtils.ts

Line 1973 in 1641532

reportOption.isBold = shouldBoldTitleByDefault || shouldUseBoldText(reportOption);

App/src/libs/OptionsListUtils.ts

Lines 2502 to 2504 in 1641532

	function shouldUseBoldText(report: ReportUtils.OptionData): boolean {
	return report.isUnread === true && ReportUtils.getReportNotificationPreference(report) !== CONST.REPORT.NOTIFICATION_PREFERENCE.MUTE;
	}

Then, for the selected options, the item doesn't have isBold property,

App/src/components/Search/SearchFiltersChatsSelector.tsx

Lines 85 to 94 in 0f2de40

	const formattedResults = OptionsListUtils.formatSectionsFromSearchTerm(
	cleanSearchTerm,
	selectedOptions,
	chatOptions.recentReports,
	chatOptions.personalDetails,
	personalDetails,
	false,
	);
	newSections.push(formattedResults.section);

and it will be bold if isBold is not false.

App/src/components/SelectionList/InviteMemberListItem.tsx

Line 101 in 49b0051

item.isBold !== false && styles.sidebarLinkTextBold,

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

The solution is to always bold the title. To do that, add a new param to getSearchOptions for shouldBoldTitleByDefault and use that instead of always setting it to false.

App/src/libs/OptionsListUtils.ts

Line 2067 in 49b0051

shouldBoldTitleByDefault: false,

function getSearchOptions(options: OptionList, searchValue = '', betas: Beta[] = [], shouldBoldTitleByDefault = false): Options {
...
const optionList = getOptions(options, {
    ...
    shouldBoldTitleByDefault,
});

App/src/components/Search/SearchFiltersChatsSelector.tsx

Line 68 in 49b0051

return OptionsListUtils.getSearchOptions(options);

return OptionsListUtils.getSearchOptions(options, undefined, undefined, true);

[ikevin127]

Sure, we can take contributors too

In this case, thanks everyone for the proposals!

I think @dominictb's proposal makes sense as the RCA is straight-forward and the main solution solves the issue as per the Expected result, without affecting other parts of the app other than the SearchFiltersChatsSelector, specifically the In filter.

• @luacmartins Before we actually attempt to address this issue, given my recent review of PR #49186 from issue [Search v2.2] Create Pinned status for chats #48823 - is this issue even worth being fixed given that the In and Has filters will be deprecated ?

🎀👀🎀 C+ reviewed

[melvin-bot]

Current assignee @luacmartins is eligible for the choreEngineerContributorManagement assigner, not assigning anyone new.

[ikevin127]

@bernhardoj Feel free to let us know if you think the selected proposal's main solution has some pitfalls which would create regressions whereas your solution won't - I'd be happy to re-assign!

[bernhardoj]

@ikevin127 I don't think there will be a regression, but both solutions actually have different results. My solution will bold all the title instead of depends on the unread status.

[luacmartins]

@Expensify/design what's the expected behavior for the In filter? Should report names be always bold, regular, or bold depending on unread status?

[dubielzyk-expensify]

My assumption here is that they should always be bold like we you submit a regular expense. Keen to hear what rest of @Expensify/design thinks though

[dominictb]

@dubielzyk-expensify

I believe the behavior of the In filter should align with that of the /chat-finder page, as both are used for searching reports, which can be bold based on unread status.

In contrast, the participant selector in the expense flow and start chat feature is used to search for individuals, rooms, or workspaces.

[dubielzyk-expensify]

Yeah, I see what you're saying, but I don't think this is an instance where we need to tell the user which are unread/read (needless complexity in this instance IMO). I think of this more as a picker-style which we tend to keep all bold. Happy for @Expensify/design to tell me otherwise though 😄

[luacmartins]

I agree! 👍 for going with all bold

[shawnborton]

I think if we're displaying these rows the same way that we display the finder page, where we have the report title above and a preview of the latest message below, then it should follow the same behavior as the chat finder where unreads are bold and reads are not.

If this follows the same behavior as the participant selector page, then they all should be bold.

[trjExpensify]

I think if we're displaying these rows the same way that we display the finder page, where we have the report title above and a preview of the latest message below

Interestingly on this, the defaultRooms (i.e #admins and announce) use the workspaceName as the second line in the chat switcher, whereas the user created rooms seem to use the lastMessage text. I know we did the former for ease of reference and discovery when looking for the room for a particular workspace. Was it intentional not to follow suit with the user created rooms in the chat switcher, or is that just an oversight?

[shawnborton]

Hmm no idea, but I would think we should standardize on message preview in the chat finder, and then just use the Workspace label in the Submit flow/participant selector.

[ikevin127]

Not overdue, still discussing about the right solution based on which we will assign one of the two existing proposals.

[trjExpensify]

but I would think we should standardize on message preview in the chat finder, and then just use the Workspace label in the Submit flow/participant selector.

Why not standardise on the workspaceName as the second line for all workspace rooms and chats in both the switcher and the participant selector?

If you're trying to find say the #admins room and we don't include the workspace name it's going to be much harder to figure out which workspace its for. We can't rely on avatar being the sole distinction, really.

[shawnborton]

That's fair, though there is a conversation happening about adding the workspace name right before the report name - so that would solve that issue and then make sure we have 100% consistency between LHN and Find. Thoughts on something like that?

[trjExpensify]

Ah, that would solve it if it's searchable by workspace name still. Do we have an issue for it? I would think we need to do that first before changing the defaultRooms to drop the workspace name, because I think that would break the guides' ability to find the admins rooms of deals they're working with if we do it before.

[shawnborton]

Here's the thread where it was being discussed.

I am fine doing nothing for now with the preview line until something like the above is in place.

[trjExpensify]

Yep, sounds good! 👍

[ikevin127]

Can we have a summary of the discussions and an update on the expected result (if changed) ? We need to know whether or not we go with the assigned proposal 👍