[$250] LHN - LHN displays employee name instead of workspace name and vice versa

[lanitochka17]

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.0.41-2
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Email or phone of affected tester (no customers): [email protected]
Issue reported by: Applause - Internal Team

Action Performed:

Option 1:

1. Navigate to https://staging.new.expensify.com/
2. As User A, create a new workspace
3. Go to the Members section and add User B as an employee
4. Log in as User B and go to the Inbox, then observe the workspace created by User A
5. In the LHN , click on the workspace chat

Option 2 (If Option 1 doesn't reproduce the issue):
Follow steps 1-3 above
4. As User A, go to the Inbox and observe the employee workspace chat
5. In the LHN, click on the employee's workspace chat

Expected Result:

• Option 1: The LHN should display the workspace name in the Inbox, not the employee's name
• Option 2: The LHN should display the employee name in the workspace chat, not the workspace name

Actual Result:

• Option 1: In step 4, the LHN initially displays User B's(employee's) name instead of the workspace name. After clicking on it, the name changes to the correct workspace name
• Option 2: In step 4, the LHN initially displays the workspace name instead of User B's name. After clicking on it, the name changes to the employee name (User B)

Workaround:

Unknown

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

Bug6619386_1727621597224.2.mp4

Bug6619386_1727621597219.1.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021840938166093058581
• Upwork Job ID: 1840938166093058581
• Last Price Increase: 2024-10-01
• Automatic offers:
• ZhenjaHorbach | Reviewer | 104228120

Issue Owner

Current Issue Owner: @bondydaa

[melvin-bot]

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

[lanitochka17]

@jliexpensify FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors

[melvin-bot]

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

[melvin-bot]

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

[MelvinBot]

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

[jliexpensify]

Hmm I can't seem to reliqably reproduce this. @ZhenjaHorbach - any luck? If you can, we can look at fixing this.

[ZhenjaHorbach]

Hmm I can't seem to reliqably reproduce this. @ZhenjaHorbach - any luck? If you can, we can look at fixing this.

I'll try to reproduce it today !

[jliexpensify]

Just a heads up @ZhenjaHorbach - I am OOO from the 3rd to 14th. I won't reassign this as I don't think any payments will be needed during this time.

[ZhenjaHorbach]

Hmmmm
On the second try I was able to reproduce it ! (Used new accounts)

And looks like FE issue since when we get MissingOnyxMessages we have all information
but I may be wrong
I'll check in more detail today or tomorrow

[jliexpensify]

Nice, ty! Sorry - to clarify, you think this will be a back-end issue?

[ZhenjaHorbach]

Nice, ty! Sorry - to clarify, you think this will be a back-end issue?

I haven't checked this issue in detail yet
But to me it looks like FE issue !

[narefyev91]

Hi, I'm Nicolay from Callstack - expert contributor group - and I would like to work on this issue.

[melvin-bot]

📣 @ZhenjaHorbach 🎉 An offer has been automatically sent to your Upwork account for the Reviewer role 🎉 Thanks for contributing to the Expensify app!

Offer link
Upwork job

[jliexpensify]

All yours @narefyev91 - thanks!

[narefyev91]

Updated from my side - still investigating - but potentially can be BE issue. Will run some more tests and provide tomorrow my findings

[narefyev91]

My discovers so far:
Option 1:
When some invite user A to the workspace - user A get latest information from MissingOnyxMessages API call.
If we observe response which we get from MissingOnyxMessages API call - and compare it with API call when user directly click on chat - we will see that we have just one field difference:

In the code - isOwnPolicyExpenseChat is exact prop - based on which we rendering correct/incorrect header:

Seems like the root case here - API returns not correct value for isOwnPolicyExpenseChat it should be true instead of false.

Option 2:
When user A as an owner of the workspace invite member to his workspace - we fire API call - AddMembersToWorkspace - which returns isOwnPolicyExpenseChat = true:

When user A clicks directly on chat - we get from OpenReport - isOwnPolicyExpenseChat = false
Again this is one main difference between API calls:

And keep in mind that isOwnPolicyExpenseChat prop is directly influence on chat header - problem again coming from not correct isOwnPolicyExpenseChat value - it should be false instead of true.

Why the issue is happened for Option 2 just for new workspaces - answer is simple:
When you create a workspace, immediately invite member to your workspace and go back to main screen - you will automatically landed on Welcome to Admins screen (because you create a new workspace)

When user work with existed workspace, invite user and move back to main screen - user will automatically landed on new created chat (with invited member), OpenReport API will be called - and correct isOwnPolicyExpenseChat value will be set.

@ZhenjaHorbach let me know wdyt here.

[ZhenjaHorbach]

My discovers so far: Option 1: When some invite user A to the workspace - user A get latest information from MissingOnyxMessages API call. If we observe response which we get from MissingOnyxMessages API call - and compare it with API call when user directly click on chat - we will see that we have just one field difference: In the code - isOwnPolicyExpenseChat is exact prop - based on which we rendering correct/incorrect header: Seems like the root case here - API returns not correct value for isOwnPolicyExpenseChat it should be true instead of false.

Option 2: When user A as an owner of the workspace invite member to his workspace - we fire API call - AddMembersToWorkspace - which returns isOwnPolicyExpenseChat = true: When user A clicks directly on chat - we get from OpenReport - isOwnPolicyExpenseChat = false Again this is one main difference between API calls: And keep in mind that isOwnPolicyExpenseChat prop is directly influence on chat header - problem again coming from not correct isOwnPolicyExpenseChat value - it should be false instead of true.

Why the issue is happened for Option 2 just for new workspaces - answer is simple: When you create a workspace, immediately invite member to your workspace and go back to main screen - you will automatically landed on Welcome to Admins screen (because you create a new workspace) When user work with existed workspace, invite user and move back to main screen - user will automatically landed on new created chat (with invited member), OpenReport API will be called - and correct isOwnPolicyExpenseChat value will be set.

@ZhenjaHorbach let me know wdyt here.

Oh
Thanks for the detailed investigation
I'll check it out over the weekend !

[melvin-bot]

@bondydaa, @narefyev91, @jliexpensify, @ZhenjaHorbach 8 days overdue is a lot. Should this be a Weekly issue? If so, feel free to change it!

[bondydaa]

haven't had a chance to fully dive into the backend here.

[bondydaa]

asked internally here if someone could take this over for me https://expensify.slack.com/archives/C03TQ48KC/p1729107652728169

[ZhenjaHorbach]

Not overdue

[melvin-bot]

@bondydaa, @narefyev91, @jliexpensify, @ZhenjaHorbach Eep! 4 days overdue now. Issues have feelings too...

[bondydaa]

no update, merge account project and deployer week taking priority.

[melvin-bot]

@bondydaa @narefyev91 @jliexpensify @ZhenjaHorbach this issue is now 4 weeks old, please consider:

• Finding a contributor to fix the bug
• Closing the issue if BZ has been unable to add the issue to a VIP or Wave project
• If you have any questions, don't hesitate to start a discussion in #expensify-open-source

Thanks!

[melvin-bot]

@bondydaa, @narefyev91, @jliexpensify, @ZhenjaHorbach Eep! 4 days overdue now. Issues have feelings too...

[bondydaa]

bumped the internal thread to see if someone can take it over https://expensify.slack.com/archives/C03TQ48KC/p1730219453170949?thread_ts=1729107652.728169&cid=C03TQ48KC

[grgia]

@ZhenjaHorbach @narefyev91 it makes sense to fix the result of isOwnPolicyExpenseChat to match- but does the header actually need to be based on this variable for workspaces?

[melvin-bot]

@bondydaa, @narefyev91, @jliexpensify, @ZhenjaHorbach Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[ZhenjaHorbach]

@ZhenjaHorbach @narefyev91 it makes sense to fix the result of isOwnPolicyExpenseChat to match- but does the header actually need to be based on this variable for workspaces?

Since we use common function for header

App/src/libs/ReportUtils.ts

Lines 2795 to 2805 in bfce277

	function getPolicyExpenseChatName(report: OnyxEntry<Report>, policy?: OnyxEntry<Policy>): string | undefined {
	const ownerAccountID = report?.ownerAccountID;
	const personalDetails = allPersonalDetails?.[ownerAccountID ?? -1];
	const login = personalDetails ? personalDetails.login : null;
	// eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing
	const reportOwnerDisplayName = getDisplayNameForParticipant(ownerAccountID) || login || report?.reportName;
	// If the policy expense chat is owned by this user, use the name of the policy as the report name.
	if (report?.isOwnPolicyExpenseChat) {
	return getPolicyName(report, false, policy);
	}

I think it's normal
And fixing isOwnPolicyExpenseChat on BE is make sense !

[melvin-bot]

@bondydaa, @narefyev91, @jliexpensify, @ZhenjaHorbach Still overdue 6 days?! Let's take care of this!

[bondydaa]

I think what @grgia is getting at is why do we display a different name when report.isOwnPolicyExpenseChat is truthy/falsy and instead should we just always be getting the policy name?

The last time it was touched was 73d6d6ef8013 which was just a typescript refactor so that doesn't give us much context there.

I don't really have much context here at all but to me it seems like if it's a policyExpenseChat then we should probably be loading the workspace name via getPolicyName whether or not you own it.

From a quick scan of this value in the backend it isn't used really in relation to the report name and is more used for checking permissions of write activity.

[melvin-bot]

@bondydaa, @narefyev91, @jliexpensify, @ZhenjaHorbach Huh... This is 4 days overdue. Who can take care of this?

[melvin-bot]

@bondydaa, @narefyev91, @jliexpensify, @ZhenjaHorbach Still overdue 6 days?! Let's take care of this!

[jliexpensify]

Posted for a new Engineer here: https://expensify.slack.com/archives/C01SKUP7QR0/p1731577486016599

[jliexpensify]

Posted in the #convert room for a new Engineer: https://expensify.slack.com/archives/C07HPDRELLD/p1731896542353939