[$500] Task - User C appears on User B's LHN when task assigned to User B is changed to User C by User A

[lanitochka17]

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. Go to staging.new.expensify.com
2. As User A, create a task and assign it to User B
3. As User A, go to the task report and change the assignee from User B to User C
4. As User B, go to LHN

Expected Result:

User C will not appear in User B's LHN

Actual Result:

User C appears in User B's LHN and it disappears with not here page when User B opens User C's report

Workaround:

Unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

• [x] Android / native
• [x] Android / Chrome
• [x] iOS / native
• [x] iOS / Safari
• [x] MacOS / Chrome / Safari
• [x] MacOS / Desktop

Version Number: 1.3.74-0

Reproducible in staging?: Yes

Reproducible in production?: Yes

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

https://github.com/Expensify/App/assets/78819774/a064a018-d660-4d0b-86e7-398caa98b2d5

Expensify/Expensify Issue URL:

Issue reported by: Applause - Internal Team

Slack conversation:

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01c82bc1ac5dd8430a
• Upwork Job ID: 1709612411890421760
• Last Price Increase: 2023-10-04

[melvin-bot[bot]]

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

[melvin-bot[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

[trjExpensify]

@thienlnam can you clarify the behaviour here to understand how this should work?

• A task was assigned to userB, and therefore the taskReport created is a thread on the userA <> userB DM
• The taskReport gets re-assigned to userC, and therefore the taskReport thread is moved to the userA <> userC DM which is now it's parent chat
• userB loses access to the taskReport after being unassigned.

Is that how it works?

[thienlnam]

Ah close but the taskReport is independent of these threads

A task was assigned to userB

• Task report is created
• A reportAction linking userB to the task is added on the user A <> userB DM

The task gets re-assigned to userC

• The task report is shared with userC, but should also remain shared with UserB and UserA
• A reportAction linking userC to the task is added on the user A <> userC DM

UserB should not lose access to the taskReport

I think the issue here is that UserB should not be losing access to that task report

[trjExpensify]

Oh, so taskReports don't have a parentChat like expense/iou/threadReports do?

What reason does userB have to still be shared the taskReport after being unassigned, and has this ever worked, so it's deemed a bug?

[thienlnam]

No they still have a parent like those reports - I might have been confused on the

the taskReport created is a thread on the userA <> userB DM

What reason does userB have to still be shared the taskReport after being unassigned

A task is basically a thread with a completion state, so if they participate in the report at all they would still have access to it.

and has this ever worked, so it's deemed a bug?

Yeah this should be working already so it would be a bug

[trjExpensify]

No they still have a parent like those reports - I might have been confused on the

Cool, that's an accurate statement though, right? The taskReport has a parentChat and that's the DM between userA <> userB, like an expense/iou/chat report are considered threads of the parent.

1. A task is created by userA and assigned to userB
2. A taskReport is created, with the userA <> userB DM as the parentChat
3. userA re-assigns the task to userC and that shares the taskReport with userC
4. The taskReport remains as a thread of the userA <> userB DM, shared with userB, and despite now being assigned to userC.

A task is basically a thread with a completion state, so if they participate in the report at all they would still have access to it.

Are you saying then if a task is assigned to userB, but they don't participate in the taskReport (i.e comment, or edit it) then the wouldn't have access after being unassigned?

[thienlnam]

Yes that's correct - the taskReport has a parent (chat or task) and it is where-ever the task was created

The taskReport remains as a thread of the userA <> userB DM, shared with userB, and despite now being assigned to userC.

Yup, but in this situation there is another parent of the user A <> userC DM that links to the taskReport, but the true 'parent' of the task still remains in the reportAction from the userA <> userB DM. Let me know if that part makes sense as it is kind of confusing. There are many links to the taskReport depending on how many times you re-assign it, but the parent will always be the original reportAction that created the task

Are you saying then if a task is assigned to userB, but they don't participate in the taskReport (i.e comment, or edit it) then the wouldn't have access after being unassigned?

Ah no, they would still have access from being the assignee. We don't ever unshare the task report with someone once they have access to it

[trjExpensify]

Cool, I think we need to consider updating the parentChat when the task is reassigned. Here's a good example of why when it comes to the logic being updated wrt to the GBR: https://expensify.slack.com/archives/C02MW39LT9N/p1695898060546159?thread_ts=1695897345.190449&cid=C02MW39LT9N

[trjExpensify]

Coming back to this. @jack, did you review the linked convo? For this issue I think this is where I'm at:

1. The DM between userA <> userC shouldn't be popping up in the LHN of userB like in the OP. That's a bug in itself to resolve in the current implementation
2. The parentChat not being the DM shared between the task creator and current assignee isn't a solution that will scale with the wider notion of the GBR being added to the "higher context" chat, so we should rethink how to solve that.

[thienlnam]

Took a brief look, but yeah this seems like it will take a larger conversation as updating the parentChat everytime the task is reassigned might have some other unintended consequences. I'm mostly OOO this week, but can start a convo next week about this

(Assigning to myself for tracking)

[trjExpensify]

Cool, so let's move this issue on for proposals to resolve this one in the current imp:

The DM between userA <> userC shouldn't be popping up in the LHN of userB like in the OP. That's a bug in itself to resolve in the current implementation

Then yeah, let's talk about this one separately somewhere. How are we going to align taskReports with this notion of the higher context chat getting the GBR when that chat could very well not be one the assignee has access to.

The parentChat not being the DM shared between the task creator and current assignee isn't a solution that will scale with the wider notion of the GBR being added to the "higher context" chat, so we should rethink how to solve that.

[melvin-bot[bot]]

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

[melvin-bot[bot]]

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

[tsa321]

Maybe back end issue? There is pusher event for user B with onyx method set of a report/chat between user A and user C that user B mustn't know about it.

[trjExpensify]

Perhaps! @thienlnam might be able to confirm.

[melvin-bot[bot]]

@trjExpensify @thienlnam @robertKozik this issue was created 2 weeks ago. Are we close to approving a proposal? If not, what's blocking us from getting this issue assigned? Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

[melvin-bot[bot]]

@trjExpensify, @thienlnam, @robertKozik Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[trjExpensify]

waiting on @thienlnam to confirm this.

[thienlnam]

Yeah I think that might be the case - seems like we're sending the new chat report to all participants but should not be sending it to people that are not included in the chat

[melvin-bot[bot]]

Current assignee @robertKozik is eligible for the Internal assigner, not assigning anyone new.

[thienlnam]

I can get a PR up for it this week

[trjExpensify]

Sounds good!

[trjExpensify]

Oh, should the reviewing label be on this?

[thienlnam]

Yup, PR has been merged now just pending deploy to see if it fixes this issue

[trjExpensify]

Dope!

[melvin-bot[bot]]

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

[thienlnam]

Should be resolved now, can we see if it's still a problem and then close if not?

[trjExpensify]

@lanitochka17 can we have the team retest this one please? Thanks!

[lanitochka17]

@tjferriss Issue is not reproducible on latest build 1.3.90-1

https://github.com/Expensify/App/assets/78819774/2f4a5203-6fcb-4dae-ae3d-465f1ad8b4f8

[trjExpensify]

Excellent - thanks for that! As this was reported by Applause and a backend PR, closing it out!