[HOLD for payment 2024-08-23] [$500] Some chats are showing as bold (unread) in the chat search, but showing as non-bold (read) in 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:
Reproducible in staging?: Needs Reproduction
Reproducible in production?: Needs reproduction
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: @tgolen
Slack conversation: https://expensify.slack.com/archives/C05LX9D6E07/p1722266268926929

Action Performed:

1. Open up the chat search
2. Look for some group channels like #social

Expected Result:

The same chats that are showing bold in the LHN should be shown as bold in the chat search results

Actual Result:

Sometimes, chats will be bolded in the search results when they are not bolded in the LHN. This can happen for chats that you have muted (the search results will still show them as unread, while the LHN shows them as read).

Workaround:

Can the user still use Expensify without this being fixed? Have you informed them of the workaround?

Platforms:

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

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

Screenshots/Videos

Add any screenshot/video evidence

log.txt

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01803b7fcbf92fa7d7
• Upwork Job ID: 1818654097937596043
• Last Price Increase: 2024-07-31

Issue Owner

Current Issue Owner: @s77rt

[melvin-bot]

Current assignee @tgolen is eligible for the AutoAssignerNewDotQuality assigner, not assigning anyone new.

[melvin-bot]

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

[MelvinBot]

This has been labelled "Needs Reproduction". Follow the steps here: https://stackoverflowteams.com/c/expensify/questions/16989

[iwiznia]

We might be just removing the bolding there. Discussion here https://expensify.slack.com/archives/C03U7DCU4/p1722269953413229

[tgolen]

In that thread, we had 8 👍 for removing the bold styling from the search options, so let's pursue that.

[melvin-bot]

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

[melvin-bot]

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

[daledah]

Proposal

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

Sometimes, chats will be bolded in the search results when they are not bolded in the LHN.

What is the root cause of that problem?

We are using isBold: true:

App/src/pages/ChatFinderPage/index.tsx

Line 123 in d2ac23b

data: recentReports.map((report) => ({...report, isBold: report.isUnread})),

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

Always use isBold: false instead
We should apply isBold: false in

App/src/pages/ChatFinderPage/index.tsx

Line 123 in 00b405e

data: recentReports.map((report) => ({...report, isBold: report.isUnread})),

App/src/pages/ChatFinderPage/index.tsx

Line 130 in 00b405e

data: localPersonalDetails,

and

App/src/pages/ChatFinderPage/index.tsx

Line 137 in 00b405e

data: [userToInvite],

What alternative solutions did you explore? (Optional)

We can create a new prop shouldUseBold style in UserListItem and then update:

App/src/components/SelectionList/UserListItem.tsx

Line 126 in 778a141

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

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

and in case of ChatFinderPage, use shouldUseBold as false

[daledah]

Proposal updated

[s77rt]

@daledah Thanks for the proposal. RCA and solution looks good to me.

🎀 👀 🎀 C+ reviewed
Link to proposal

[melvin-bot]

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

[melvin-bot]

📣 @daledah You have been assigned to this job!
Please apply to the Upwork job and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review 🧑‍💻
Once you apply to this job, your Upwork ID will be stored and you will be automatically hired for future jobs!
Keep in mind: Code of Conduct | Contributing 📖

[daledah]

@tgolen I see we have a lot of search screen, such as chat finder, new chat, ... The change "removing the bold styling from the search options" is only applied to chat finder, right?

[tgolen]

Let me ask about that! I'll get back to you on it.

[tgolen]

Sorry... I'm going to put a HOLD on this for a second. We had some more discussion internally, and we'd like to change the assumption of this GH.

We'd actually like to better understand why the search results do not match the LHN. In other words, why does the LHN show the chat as unread, but the search results show it as being read? There must be some kind of a bug or issue happening in there. Rather than just covering it up by never showing them as bold, let's instead focus on fixing the issue with the read/unread status.

@daledah Is this something you can look into and can reproduce or do you need more debugging or troubleshooting from me?

[daledah]

@tgolen There are a lot of cases, where the LHN does show the report with bold style but the search result show as bold style.

1. In this case (video below), let's consider report named "Test Parent". I set the that report with notificationPreference is mute, then marked it as unread. Now the LHN does not show a bold style, because of:
   

   App/src/components/LHNOptionsList/OptionRowLHN.tsx

   Lines 87 to 88 in b147b62

   	const textUnreadStyle = optionItem?.isUnread && optionItem.notificationPreference !== CONST.REPORT.NOTIFICATION_PREFERENCE.MUTE ? [textStyle, styles.sidebarLinkTextBold] : [textStyle];
   	const displayNameStyle = [styles.optionDisplayName, styles.optionDisplayNameCompact, styles.pre, textUnreadStyle, style];

   
   but the search results show a bold style, because of:
   

   App/src/pages/ChatFinderPage/index.tsx

   Line 123 in b147b62

   data: recentReports.map((report) => ({...report, isBold: report.isUnread})),

   
   

   App/src/components/SelectionList/UserListItem.tsx

   Line 126 in b147b62

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

Screen.Recording.2024-08-02.at.22.25.26.mov

2. In this case (video below), let consider the report named "Expensify". In this case, LHN displays it without bold style. But in search result, that result comes from
   

   App/src/pages/ChatFinderPage/index.tsx

   Lines 128 to 133 in b147b62

   	if (localPersonalDetails.length > 0) {
   	newSections.push({
   	data: localPersonalDetails,
   	shouldShow: true,
   	});
   	}

   
   with isBold is undefined. So it will display bold style because of:
   

   App/src/components/SelectionList/UserListItem.tsx

   Line 126 in b147b62

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

Screen.Recording.2024-08-02.at.22.36.13.mov

[tgolen]

Wow, thanks. OK, I realized today that I had the #social channel muted 😊 but... I still think the search results should mimic what the LHN does in both cases above. Would you be willing to include those changes on your PR? If it increases the scope enough, I can consider bumping up the price of the issue to account for it.

[daledah]

I still think the search results should mimic what the LHN does in both cases above. Would you be willing to include those changes on your PR

Is the goal of this issue to remove the bold styling from the search options? If that's the case, it conflicts with the requirement you've mentioned above.

[tgolen]

Yeah, as I mentioned in my previous comment:

We had some more discussion internally, and we'd like to change the assumption of this GH.

I will adjust the description and title of the GH.

[daledah]

I noticed the updated description. Should we remove the 'HOLD' label before I continue working on the PR?

[tgolen]

Oh, thanks for the reminder. I've removed the HOLD.

[abekkala]

@daledah is there an update on the PR for this one?

[s77rt]

@abekkala PR is merged and deployed to production 5 days ago

[abekkala]

Deployed to prod. August 16

PAYMENT SUMMARY FOR AUG 23, if no regressions

• Fix: @daledah [$250] Offer
• PR Review: @s77rt [$250] Payment via NewDot
  Please complete checklist

---

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [@s77rt] The PR that introduced the bug has been identified. Link to the PR:
• [@s77rt] 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:
• [@s77rt] 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:
• [@s77rt] Determine if we should create a regression test for this bug.
• [@s77rt] 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.
• [@abekkala] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[s77rt]

• The PR that introduced the bug has been identified: Only bold user display name when it's unread in search page #37306
• The offending PR has been commented on: Only bold user display name when it's unread in search page #37306 (comment)
• A discussion in #expensify-bugs has been started: Not needed
• Determine if we should create a regression test for this bug: No

[daledah]

Would you be willing to include those changes on your PR? If it increases the scope enough, I can consider bumping up the price of the issue to account for it.

@tgolen The PR is ready to review before we decide to change the expected behavior. Then I need to revert all the changes and implement the fresh PR. Also, based on your comment, should we consider increasing the issue's price?

cc @abekkala

[tgolen]

Yeah, I think increasing the price is appropriate. @abekkala Could you please increase the price of this issue to $500?

[melvin-bot]

⚠️ Failed to update price automatically. The BZ team member will need to update the price manually in Upwork.

[abekkala]

UPDATED PAYMENT SUMMARY FOR AUG 23

• Fix: @daledah [$500] UPDATED OFFER
• PR Review: @s77rt [$500] Payment via NewDot

[abekkala]

@daledah payment sent and contract ended - thank you! 🎉

[JmillsExpensify]

$500 approved for @s77rt

[tgolen]

This is still happening for me. Notice my LHN in focus mode:

While the chat search has many bolded reports (I see about 30 as I scroll down):

[s77rt]

@tgolen This is looking to be working as expected, chats that are bold/normal are consistent in the LHN and the find page.

[tgolen]

How can you explain my screenshots then?

[s77rt]

@tgolen Chats that are bold in screenshot1 are also bold in screenshot2 and vice-versa. If you are referring to the missing chats, that's a different bug.

[tgolen]

OK, I see what you're saying. You're right, I'm specifically speaking about unread chats missing from my LHN. I can open a new issue for that.

[s77rt]

@tgolen The chats not being listed is probably because their notificationPreference is set to hidden. Maybe that's the expected behaviour?

App/src/libs/SidebarUtils.ts

Lines 140 to 142 in 3b15d84

	if (isHidden && !shouldOverrideHidden) {
	return;
	}

[tgolen]

You could be right about that. I spot checked a few, and it looks like it matches your theory. So, in this case, I would say this makes for a pretty confusing UX for the user. I wonder if maybe we shouldn't be showing them as bold if you have hidden preference. That would certainly have kept me from bringing this up at all.

Maybe this is something we should discuss back in Slack to get consensus on?

cc @ZhenjaHorbach and @nkdengineer

[s77rt]

Makes sense but let's ask in Slack to be sure