[LOW] [Splits] Task - Task report avatar in LHN shows task assignee instead of task creator before opening it

[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: 1.4.15-4
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 and B have no prior chat and they are on private domain

1. [User A] In 1:1 DM with User C. create a task and assign it to User B
2. [User B] Note the avatar of task report in LHN
3. [User B] Open the task report

Expected Result:

In Step 2, when User B receives the task, the task report avatar should display the avatar of task creator

Actual Result:

In Step 2, when User B receives the task, the task report avatar displays task assignee avatar (User B) instead of task creator avatar
The task report avatar only shows the correct avatar (task creator) after opening the task report in Step 3

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

Bug6323106_1703187095047.bandicam_2023-12-22_00-33-54-109.1.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01dd3b25a9441185ce
• Upwork Job ID: 1737965082987188224
• Last Price Increase: 2023-12-21

Issue Owner

Current Issue Owner: @roryabraham

[github-actions]

👋 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 @roryabraham (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

[roryabraham]

Weird

[roryabraham]

Well what I'm seeing is that in step 2, the ownerAccountID is user A and the mangagerAccountID on the report is user B. Now going to click on the report as user B and see what happens.

[roryabraham]

Clarification – I was looking at the task report, but there's also a chat report that's created between users A and B

[roryabraham]

So it looks like the chat report that's optimistically created when assigning the task has the wrong participantAccountIDs

[roryabraham]

Or rather, not just the one that's optimistically created, but the one that user B receives via Pusher

[roryabraham]

Before user B clicks on the report, the participantAccountIDs array just had the accountID of B, in this case [185]. But after user B clicks on the report, the participantAccountIDs array had just the accountID of B, in this case [186].

Furthermore, I don't see any code that optimistically generates the chat report in this case.

[roryabraham]

Edit: the chat report is optimistically generated here, and the participantAccountID array is correct for the person who created the report.

[roryabraham]

At this point, I'm pretty sure that this is a back-end issue, so I'm going to remove the deploy blocker label and check this off.

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to Contributor Plus for review of internal employee PR - @fedirjh (Internal)

[roryabraham]

In short, the problem here is:

• When user A uses CreateTask to create a chat report with user B:
  • the participantAccountIDs returned by the API for user A is (correctly?) [$userBAccountID]
  • the participantAccountIDs returned by the API for user B is (incorrectly?) [$userBAccountID] (i.e: the participantAccountIDs are not tailored for each users' perspective.
• When user B uses OpenReport to open that same report, then participantAccountIDs is corrected to be [$userAAccountID]

[roryabraham]

I'm thinking that an approach to solving this might be to leverage ReportUtils::pushNewChat in ReportUtils::getOnyxDataForNewTaskAssignee. There's some logic in ReportUtils::pushNewChat that sends a different value for participantAccountIDs to each participant, excluding the recipient. That's what we need to use here.

I also notice that it looks like some of the Onyx post-processing could be DRYed up between ReportAPI::createTask and ReportAPI::editTask.

Alternatively, we could make the jump to true 1:1:1 and move all the Onyx logic from PHP to Auth for both CreateTask and EditTask.

[roryabraham]

cc @thienlnam for a buddy check

[thienlnam]

It seems odd to me that the participantAccountIDs change based on who is opening the report - Is this something we updated recently? I would expect that they would always be the same regardless of who is opening it and then the personalDetails would be different depending on the user

When user B uses OpenReport to open that same report, then participantAccountIDs is corrected to be [$userAAccountID]

I would check why this is the case, we haven't historically included the report creator in the participants so there might have been a recent change (maybe for UCR?)

I'm sure your approach would work, and maybe the correct solution if it's intended that the participantAccountIDs are now intended to be different per user

[kavimuru]

Issue is reproducible still.

bandicam.2024-04-15.22-31-04-118.mp4

[roryabraham]

Ok, unfortunate that this is still reproducible. Will need to circle back

[melvin-bot]

This issue has not been updated in over 15 days. @sonialiap, @fedirjh, @roryabraham eroding to Monthly issue.

P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

[roryabraham]

unassigning myself as I'm not sure when I'll be able to prioritize this

[sonialiap]

@saracouto this issue was moved to "paused" and it's been open since December, should we close this out?

[sonialiap]

Paused

[sonialiap]

Asking for a retest

[sonialiap]

asked for new retest - slack

[mvtglobally]

Not reproducible
https://github.com/user-attachments/assets/7cc093ec-842d-4627-8216-9fec86ec5b3a