Workspace rooms details page display user list in place of room name

[kavimuru]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Action Performed:

1. Open the app
2. Open any workspace room report (eg room: #announce, #admin)
3. Click on header to open details page
4. Observe that on details page, app displays user list in place of room name before room profile

Expected Result:

App should display room name below room profile on room details page

Actual Result:

App displays user list instead of room name below room profile on room details page

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 / Chrome
• iOS / native
• iOS / Safari
• MacOS / Chrome / Safari
• MacOS / Desktop

Version Number: v1.3.44-0
Reproducible in staging?: y
Reproducible in production?: n
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
Notes/Photos/Videos: Any additional supporting documentation

user.list.in.place.of.room.name.mp4

Expensify/Expensify Issue URL:
Issue reported by: @dhanashree-sawant
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1690038296569129

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @maddylewis (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[melvin-bot]

Bug0 Triage Checklist (Main S/O)

• This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• This bug is not a duplicate report (check E/App issues and #expensify-bugs)
  • If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
• This bug is reproducible using the reproduction steps in the OP. S/O
  • If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
  • If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
• This issue is filled out as thoroughly and clearly as possible
  • Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
• I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[OSBotify]

👋 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]

Triggered auto assignment to @cristipaval (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

[BhuvaneshPatil]

Proposal

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

Workspace rooms details page display user list in place of room name

What is the root cause of that problem?

This is caused by - #23255

For showing full title we are using shouldUseFullTitle prop.

App/src/pages/ReportDetailsPage.js

Lines 152 to 159 in b7d17e0

	<DisplayNames
	fullTitle={ReportUtils.getReportName(props.report)}
	displayNamesWithTooltips={displayNamesWithTooltips}
	tooltipEnabled
	numberOfLines={1}
	textStyles={[styles.textHeadline, styles.textAlignCenter, styles.pre]}
	shouldUseFullTitle={shouldUseFullTitle}
	/>

For calculating that we are using shouldDisableSettings -

!isPolicyExpenseChat(report) && !isChatRoom(report) && !isChatThread(report)

Before this we used - isChatRoom || isPolicyExpenseChat || isThread for displaying full title.

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

We shall change -

App/src/pages/ReportDetailsPage.js

Line 158 in b7d17e0

shouldUseFullTitle={shouldUseFullTitle}

to - !shouldUseFullTitle

or we can change -

App/src/pages/ReportDetailsPage.js

Line 64 in b7d17e0

const shouldUseFullTitle = shouldDisableSettings;

to -

    const shouldUseFullTitle = !shouldDisableSettings;

Both are same thing

What alternative solutions did you explore? (Optional)

We can also change it to - shouldUseFullTitle || ReportUtils.isTaskReport(props.report)

I can make a PR right away to fix this.

[c3024]

Proposal

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

On clicking policy room header, the right hand panel shows usernames at room name

What is the root cause of that problem?

App/src/components/DisplayNames/index.js

Lines 88 to 90 in cd851d0

	{this.props.shouldUseFullTitle
	? this.props.fullTitle
	: _.map(this.props.displayNamesWithTooltips, ({displayName, accountID, avatar, login}, index) => (

Here in DIsplayNames we show reportName or participants details with tooltips depending on the boolean shouldUseFullTitle
It should be true in cases of isChatRoom which is the case here.

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

Change this here

App/src/pages/ReportDetailsPage.js

Line 64 in cd851d0

const shouldUseFullTitle = shouldDisableSettings;

to

    const shouldUseFullTitle = !shouldDisableSettings;

What alternative solutions did you explore? (Optional)

[mananjadhav]

This PR is open to resolve the regression from #22997.

cc - @cristipaval @maddylewis

[arosiclair]

I just requested to CP the fix

[marcaaron]

The fix for this here was deployed yesterday so I think the blocker is resolved here.

[maddylewis]

@arosiclair quick ques - at this point, should i have a C+ added to this issue to review the existing proposals?

[arosiclair]

This issue was already fixed by this PR.

The bug was a regression from a contributor trying to fix another issue. The same contributor and C+ (@ginsuma and @robertKozik) pushed out this fix so, in this case, I think there's no extra payment necessary. That sounds right to you @maddylewis?

[dhanashree-sawant]

Hi @arosiclair, @maddylewis, If this issue helped to change that PR for fix, will it be eligible for reporting bouns?

[arosiclair]

Not in this case. The issue was already known before you reported it. (PR was posted Jul 21 and you posted on slack Jul 22)

[maddylewis]

The bug was a regression from a contributor trying to fix another #22997. The same contributor and C+ (@ginsuma and @robertKozik) pushed out this fix so, in this case, I think there's no extra payment necessary. That sounds right to you @maddylewis?

@arosiclair - got it! thanks for the breakdown. are we now waiting for the 7-day regression period to pass before closing this one out?

[arosiclair]

Don't think that's needed either we can just use the main issue #22997. Closing this out in favor of that one