[HOLD #35539][#VIP-VSB] Thread in #admin shows Hidden with avatar placeholder in LHN for workspace member

[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!

---

WAVE/PROJECT SUGGESTION : #vip-vsb

Version Number: v1.4.31-7
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: Applause internal team
Slack conversation:

Action Performed:

Precondition:

• User A is an admin of Workspace A.
• User B is a member of Workspace A.

1. [User B] Create a room under Workspace A.
2. [User B] Invite User C to the room.
3. [User A] Go to #admin room of Workspace A.
4. [User A] Reply in thread to the system message "User B invited User C to room".
   5.[User B] Note the thread in LHN.

Expected Result:

The thread in LHN will appear with thread title and complete avatar for User B.

Actual Result:

The thread in LHN appears with "Hidden" as thread title and avatar placeholder for User B. The thread in LHN only shows the title and avatar after user opens the thread. On production, it is the same behavior except that it shows "Deleted message".

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

Bug6354278_1706164090200.20240125_130819.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01403dd68ad2cbea53
• Upwork Job ID: 1750411743673921536
• Last Price Increase: 2024-02-01

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

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

[Santhosh-Sellavel]

So far no proposals.
I'm unavailable next week, Please assign a new C+ Issue here if required, thanks!

cc: @CortneyOfstad

[CortneyOfstad]

Sounds good @Santhosh-Sellavel — we should be good, but thanks for the heads up! 👍

[nebiyuelias1]

Proposal

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

The thread in the LHN shows the wrong title when replying to a system message.

What is the root cause of that problem?

The root cause of this problem is that the parent report action is not present in Onyx. This is because the backend is not sending the right data to the FE and there is missing data being expected by the FE. For example sake let's look at the following report:

{
    ...,
    "parentReportActionID": "1720570339863409425",
    "parentReportID": "7087334114008551",
    "participantAccountIDs": [
        16310555,
        16310556
    ],
    "policyID": "0807ACCC40A5A850",
    "policyName": "Nebiyuelias1+4's Workspace 6",
    "reportID": "3278851746634061",

}

This the report object for the thread message. The FE has the following logic to construct the title:
allReportActions?.[report.parentReportID]?.[report.parentReportActionID] ?? {};
But the pusher event that is received looks like the following(when step #4 is performed):

   {
            "key": "reportActions_3278851746634061",
            "onyxMethod": "merge",
            "shouldNotify": true,
            "value": {
              ...
              }
            }
          }

Basically, the reportActions_7087334114008551 doesn't exist in onyx until the report is opened and hence the FE is not able to get the parent report. As a result a default message is being shown.

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

I suggest we show a different title for the thread. This is because we don't have the correct data. I'm suggesting to modify the logic added by this pr #34362.

What alternative solutions did you explore? (Optional)

An easier fix is to make sure BE sends the parent report action when the add comment (step #4 in the precondition steps) action is taken.