Task – Deleted task appears on top of assignee LHN if creator delete it in group chat

[m-natarajan]

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: v9.0.10-2
Reproducible in staging?: y
Reproducible in production?: n
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):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause internal team
Slack conversation:

Action Performed:

1. Go to https://staging.new.expensify.com/

2. Log in as user A

3. Open group chat with user B

4. Create a task without assignee in the chat

5. Log in as user B in Incognito tab and open task detail

6. Assign task to me

7. Navigate to another chat

8. As user A send any comment in task detail

9. Delete the task

10. As user B observe LHN

Expected Result:

Deleted task appears not on top of LHN

Actual Result:

Deleted task appears on top of LHN

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

Bug6547691_1721435086016.Del_task.mp4

View all open jobs on GitHub

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @dangrous (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

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

[srikarparsi]

I believe this relates to the same comment from here. Before, closed tasks were being rendered as archived as shown here. This is why they also floated to the bottom. But not, they're no longer being rendered as archived which is why they're higher up in the LHN. I left a fix in the linked comment but I think this behavior might be expected as well? @puneetlath if you could take a look at this one as well that would be great. Basically, deleted tasks are moving up in the LHN (because of recent activity), rather than moving to the bottom. Conversation to follow along

[mountiny]

Coming from that discussion, I do not think this is a blocker and more so an expected behaviour now that we need to align on

[dangrous]

Yeah I agree, I think this is (new) expected behavior. Product-based question though - to me it would be confusing to see that it jumps up when deleted, but you don't actually know what task was deleted (since it only says [Deleted task]. Would it be possible / ideal to keep the task name in there, since we now know it's been deleted due to the subhead there?

Sounds like @puneetlath you'll be the best person to confirm that we should close this out. Thanks!

[puneetlath]

In general, that makes sense to me. Which sub-header though?

[dangrous]

sorry not sure what we call it - the preview in the LHN (deleted task)

Seems like it might be more helpful to say:

Go to the store
deleted task

so you know what was deleted, and it's not repetitive

[puneetlath]

Ah ok I see. I think that deleted task in the LHN is just the last message posted though. So it would go away if you posted another message in there. So if we were to do this, I think we should show somewhere within the task itself that it's deleted.

[dangrous]

Ah okay that makes sense! Adjusting that would be a follow up anyway - I'll put a note to discuss this in Slack at some point to figure out a better solution, since I think it's worth investigating.

But to confirm - this current issue as stated is not an issue, correct? We can close?

[puneetlath]

Agreed.