Repository navigation
[HOLD for payment 2024-03-07] [$500] Wrong header is shown for 2nd and 3rd level of child threads #37111
Description
Activity
- addedExternalAdded to denote the issue can be worked on by a contributorAdded to denote the issue can be worked on by a contributorDailyKSv2KSv2BugSomething is broken. Auto assigns a BugZero manager.Something is broken. Auto assigns a BugZero manager.
on Feb 22, 2024 - changed the title
[-]Wrong header is shown for 2nd and 3rd level of child threads[/-][+][$500] Wrong header is shown for 2nd and 3rd level of child threads[/+]on Feb 22, 2024 Job added to Upwork: https://www.upwork.com/jobs/~01d99f7344fe2e0a2c
- addedHelp WantedApply this label when an issue is open to proposals by contributorsApply this label when an issue is open to proposals by contributors
on Feb 22, 2024 Triggered auto assignment to Contributor-plus team member for initial proposal review - @paultsimura (
External)Triggered auto assignment to @sakluger (
Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.Proposal
Please re-state the problem that we are trying to solve in this issue.
Wrong header is displayed when you navigate into a thread. It also shows the room as being the parent.
What is the root cause of that problem?
Lines 2639 to 2650 in 0a2ece8
function getParentNavigationSubtitle(report: OnyxEntry<Report>): ParentNavigationSummaryParams { if (isThread(report)) { const parentReport = allReports?.[`${ONYXKEYS.COLLECTION.REPORT}${report?.parentReportID}`] ?? null; const {rootReportName, workspaceName} = getRootReportAndWorkspaceName(parentReport); if (!rootReportName) { return {}; } return {rootReportName, workspaceName}; } return {}; } getParentNavigationSubtitlewill callgetRootReportAndWorkspaceNameto get the report name when handling athreadreport.Lines 2590 to 2593 in 0a2ece8
if (isChildReport(report) && !isMoneyRequestReport(report) && !isTaskReport(report)) { const parentReport = allReports?.[`${ONYXKEYS.COLLECTION.REPORT}${report?.parentReportID}`] ?? null; return getRootReportAndWorkspaceName(parentReport); } getRootReportAndWorkspaceNamein turn will navigate up all the way to the root report and return it's name instead. Note how we already check forisTaskReportandisMoneyRequestReportbut notisChatReport.What changes do you think we should make in order to solve the problem?
Add a check for
isChatReportingetRootReportAndWorkspaceNameand return the correct parent report nameif (isChildReport(report) && !isMoneyRequestReport(report) && !isTaskReport(report) && !isChatReport(report)) { const parentReport = allReports?.[`${ONYXKEYS.COLLECTION.REPORT}${report?.parentReportID}`] ?? null; return getRootReportAndWorkspaceName(parentReport); }
Screen.Recording.2024-02-22.at.5.28.40.PM.mov
What alternative solutions did you explore? (Optional)
Get rid of
getRootReportAndWorkspaceNameas it appears the only scenario where we would navigate up to the root is when we're dealing withchats, and according to this issue, we might not want to do that even for chats.if (isChildReport(report) && !isMoneyRequestReport(report) && !isTaskReport(report) && !isChatReport(report)) {}
The condition above (as proposed) seems to always return false now that we added chat to the list.
isMoneyRequestReport,isTaskReportandisChatReportcovers all 4 types of reports:TYPE: { CHAT: 'chat', EXPENSE: 'expense', IOU: 'iou', TASK: 'task', },
So unless I'm missing something, we can rename
getRootReportAndWorkspaceNametogetReportAndWorkspaceNameand remove the part that it navigates to the root report. But again, I might be missing a scenario where we actually want to get to the root.Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.
I see that @chiragsalian once mentioned that it's an expected behavior: #27986 (comment)
@puneetlath @chiragsalian did the expected behavior change, and we should proceed with the proposals review here?
Proposal
Please re-state the problem that we are trying to solve in this issue.
Wrong header title shown in chat threads
What is the root cause of that problem?
On the HeaderView component, we are using the
parentNavigationSubtitleDatato get the title of the parent displayed afterFrom...
App/src/pages/home/HeaderView.js
Line 108 in cd14830
const parentNavigationSubtitleData = ReportUtils.getParentNavigationSubtitle(reportHeaderData); but this function
getParentNavigationSubtitleis usinggetRootReportAndWorkspaceName(parentReport);to turn the title of the parent report and this is wrong.
Lines 2639 to 2643 in cd14830
function getParentNavigationSubtitle(report: OnyxEntry<Report>): ParentNavigationSummaryParams { if (isThread(report)) { const parentReport = allReports?.[`${ONYXKEYS.COLLECTION.REPORT}${report?.parentReportID}`] ?? null; const {rootReportName, workspaceName} = getRootReportAndWorkspaceName(parentReport); if (!rootReportName) { As you can see from the name of the function
getRootReportAndWorkspaceName, the word ROOT is about getting details from the root, not the parent.What changes do you think we should make in order to solve the problem?
We need to get the title from the parent and not from the root. We can use
const parentReportName = getReportName(parentReport);This will turn the title of the parent and not the title of the root.
POC video:
20240223_135951.mp4
What alternative solutions did you explore? (Optional)
I can see that the function
getParentNavigationSubtitlefromReportUtilsis used by other components. I think it's better to create two fucntions, one to get Parent Title and a second for the root title and then adjust components depending on the need (root/parent).Not overdue. Waiting for a decision from @puneetlath and @chiragsalian. Also asked in Slack.
Reacted by Sasha Kluger20 remaining items
- addedWeeklyKSv2KSv2Awaiting PaymentAuto-added when associated PR is deployed to productionAuto-added when associated PR is deployed to productionand removedDailyKSv2KSv2WeeklyKSv2KSv2
on Feb 28, 2024 - changed the title
[-][$500] Wrong header is shown for 2nd and 3rd level of child threads[/-][+][HOLD for payment 2024-03-07] [$500] Wrong header is shown for 2nd and 3rd level of child threads[/+]on Feb 29, 2024 Reviewinglabel has been removed, please complete the "BugZero Checklist".The solution for this issue has been 🚀 deployed to production 🚀 in version 1.4.45-6 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:
If no regressions arise, payment will be issued on 2024-03-07. 🎊
For reference, here are some details about the assignees on this issue:
- @barros001 requires payment automatic offer (Contributor)
- @paultsimura requires payment automatic offer (Reviewer)
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:
- [@paultsimura] The PR that introduced the bug has been identified. Link to the PR:
- [@paultsimura] 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:
- [@paultsimura] 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:
- [@paultsimura] Determine if we should create a regression test for this bug.
- [@paultsimura] 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.
- [@sakluger] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:
- The PR that introduced the bug has been identified. Link to the PR: Thread subheaders and parent navigation #21092
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:This is rather a new feature request, so the original PR is not offending.- 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: N/A
- Determine if we should create a regression test for this bug: Yes
- 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
- Post "Message 1" in a room
- Click "Reply in thread" on "Message 1"
- Post "Message 2" in this thread
- Click "Reply in thread" on "Message 2"
- Verify that the report title shows "Message 2" and the subtitle shows "Message 1" as the parent navigation it.
Do we agree 👍 or 👎
Reacted by Sasha KlugerPaid everyone out and created the regression test GH issue. Thanks everyone!
Reacted by Carlos Barros

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: 1.4.43-13
Reproducible in staging?: y
Reproducible in production?: y
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: @puneetlath
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1708622339587649
Action Performed:
message 1message 2message2Expected Result:
Header should show only the thread which is 1 level up
Actual Result:
Shows "room name" and clicking on that takes to 1 level up
Workaround:
unknown
Platforms:
Which of our officially supported platforms is this issue occurring on?
Screenshots/Videos
Add any screenshot/video evidence
Recording.2767.mp4
View all open jobs on GitHub
Upwork Automation - Do Not Edit