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

lanitochka17 commented 9 months ago

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.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

[User A] In 1:1 DM with User C. create a task and assign it to User B
[User B] Note the avatar of task report in LHN
[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?

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

https://github.com/Expensify/App/assets/78819774/3c783608-b077-4a8e-9f6a-dad612a45700

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[bot] commented 9 months ago

:wave: 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:

Identify the pull request that introduced this issue and revert it.
Find someone who can quickly fix the issue.
Fix the issue yourself.

melvin-bot[bot] commented 9 months ago

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

roryabraham commented 9 months ago

Weird

roryabraham commented 9 months ago

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 commented 9 months ago

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

roryabraham commented 9 months ago

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

roryabraham commented 9 months ago

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

roryabraham commented 9 months ago

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 commented 9 months ago

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

roryabraham commented 9 months ago

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[bot] commented 9 months ago

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

melvin-bot[bot] commented 9 months ago

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

melvin-bot[bot] commented 9 months ago

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[bot] commented 9 months ago

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

roryabraham commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

cc @thienlnam for a buddy check

thienlnam commented 9 months ago

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

roryabraham commented 9 months ago

It seems odd to me that the participantAccountIDs change based on who is opening the report

Good point! That is a bit weird, I'm not sure why it was built that way. I'll look into it a bit more

melvin-bot[bot] commented 9 months ago

@sonialiap, @fedirjh, @roryabraham Whoops! This issue is 2 days overdue. Let's get this updated quick!

roryabraham commented 9 months ago

No update since OOO

roryabraham commented 9 months ago

Asked about the plan for a potentially related issue here

melvin-bot[bot] commented 9 months ago

@sonialiap, @fedirjh, @roryabraham Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

roryabraham commented 9 months ago

Alright, well this is internal and I have a few other things on my plate so I don't think I'll be able to prioritize this one this week.

The updated plan of action is to:

Update the front-end to always expect chat reports to have their full list of participants, including the current user. This will involve many changes in many places in E/App.
Update the PHP layer to stop stripping out the current user from participantAccountIDs

This will make it simpler to go full 1:1:1 in the future, but I'm not including that in the scope to fix this issue, because it would take way too much work to migrate all places where we update participantAccountIDs to perform Onyx updates from Auth.

melvin-bot[bot] commented 9 months ago

@sonialiap @fedirjh @roryabraham this issue was created 2 weeks ago. Are we close to a solution? Let's make sure we're treating this as a top priority. Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

melvin-bot[bot] commented 9 months ago

@sonialiap, @fedirjh, @roryabraham Eep! 4 days overdue now. Issues have feelings too...

roryabraham commented 9 months ago

Sorry, still no update. Maybe tomorrow, but I think more realistic goal to make progress on this is Wednesday

melvin-bot[bot] commented 9 months ago

@sonialiap @fedirjh @roryabraham this issue is now 3 weeks old. There is one more week left before this issue breaks WAQ. What needs to happen to get a PR in review this week? Please create a thread in #expensify-open-source to discuss. Thanks!

melvin-bot[bot] commented 9 months ago

@sonialiap, @fedirjh, @roryabraham Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

melvin-bot[bot] commented 8 months ago

@sonialiap, @fedirjh, @roryabraham 6 days overdue. This is scarier than being forced to listen to Vogon poetry!

roryabraham commented 8 months ago

Still no update. Going to bump this to weekly for now since I have a few higher priority items ahead of it in my TODO queue

melvin-bot[bot] commented 8 months ago

@sonialiap @fedirjh @roryabraham this issue is now 4 weeks old and preventing us from maintaining WAQ. This should now be your highest priority. Please post below what your plan is to get a PR in review ASAP. Thanks!

roryabraham commented 8 months ago

Still no update unfortunately

sonialiap commented 7 months ago

@roryabraham any updates this week? 😁

roryabraham commented 7 months ago

nope, sorry have been focused on more urgent wave work and chores.

roryabraham commented 7 months ago

Throwing this on HOLD for https://github.com/Expensify/Expensify/issues/341000 as the solution I had in mind here will be deprecated/replaced by that one

roryabraham commented 7 months ago

still on HOLD

melvin-bot[bot] commented 6 months ago

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 commented 5 months ago

taking this off HOLD and requested retest: https://expensify.slack.com/archives/C9YU7BX5M/p1713202973663399

kavimuru commented 5 months ago

Issue is reproducible still.

https://github.com/Expensify/App/assets/43996225/7e15bb08-60f7-45e6-868f-29e74fd6c6d3

roryabraham commented 5 months ago

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

melvin-bot[bot] commented 4 months ago

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 commented 4 months ago

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

sonialiap commented 3 months ago

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

sonialiap commented 2 months ago

Paused

sonialiap commented 1 month ago

I'm OOO Aug 19-30, but this is paused so not adding a leave buddy

sonialiap commented 3 weeks ago

Paused

Expensify / App